Tree Model Implementation
Hi All,
I'm need to create a JATO tree implementation and need some advice. I
want to modify the JATO sample tree implementation so that:
1) The model is cached within the user's session.
2) The model is created on demand. i.e. The data associated with the
branches are only retrieved when the branches are opened.
In the sample application E0115TreeView (view) creates a
SimpleTreeModelImpl (model) each time it is instantiated and
SimpleTreeModelImpl (model) creates dummy data each time it is
instantiated.
1) Is there a standard JATO technique for associating a model with a
view (unlike the sample)? Does this involve the ModelTypeMapImpl class?
My tree data is stored in LDAP, so I can't use a standard JATO database
Model classes.
2) The comment in the SimpleTreeModelImpl class definition indicates
that it is normal practice to store the model in the user's session. Is
there a standard JATO technique for doing this?
3) What would be the best way to extend the sample so that I can create
the model on-demand?
Regards,
Dennis Parrott.
[Non-text portions of this message have been removed]
[1270 byte] By [
Guest] at [2007-11-25 9:30:07]
hi Craig,
I have written a simple application in Jato
I am not being able to get the selected value from the
list box
i am attaching my code for the bean
pls see what is the mistake i have done as u sadi i
have done a get value but i am getting the result as
"list"
the value with which i have initilazed the
child(CHILD_LISTBOX).
pls look inot this..
and sorry for sending personal mails to u .
from now on i will be sending mail to the group id.
i hope u will respond
i am very thankful to you for ur help so far..
__
Guest at 2007-7-1 16:36:34 >
Hi Dennis--
See below.
> I'm need to create a JATO tree implementation and need some advice. I
> want to modify the JATO sample tree implementation so that:
>
> 1) The model is cached within the user's session.
>
> 2) The model is created on demand. i.e. The data associated with the
> branches are only retrieved when the branches are opened.
>
> In the sample application E0115TreeView (view) creates a
> SimpleTreeModelImpl (model) each time it is instantiated and
> SimpleTreeModelImpl (model) creates dummy data each time it is
> instantiated.
>
> 1) Is there a standard JATO technique for associating a model with a
> view (unlike the sample)? Does this involve the ModelTypeMapImpl class?
> My tree data is stored in LDAP, so I can't use a standard JATO database
> Model classes.
Not sure what you mean here. If you're talking about JATO 2.0, you just set
a ModelReference by calling setPrimaryModelReference(). If you're using a
previous version, you call setPrimaryModelClass() or setPrimaryModel(). In
the case of the ModelReference or setPrimaryModel(), you can use a model
instance that you obtain yourself, from the ModelManager, session, by direct
construction, etc.
> 2) The comment in the SimpleTreeModelImpl class definition indicates
> that it is normal practice to store the model in the user's session. Is
> there a standard JATO technique for doing this?
The normal way to obtain a Model instance is via the ModelManager. It has
flags that let you automatically obtain the Model from the session.
Similarly, in JATO 2.0, ModelReference has flags that do the same thing
(ModelReferenes use the ModelManager internally).
In your case, will you be retrieving the Model only once and then storing in
session, or will you be retrieving it on each request? If you're unsure,
you can use the session if the tree is static Otherwise, you need to obtain
it per request.
> 3) What would be the best way to extend the sample so that I can create
> the model on-demand?
What do you mean by "on-demand", in terms of frequency? The sample assumes
that all the information required to obtain the Model is available in the
ViewBean's constructor, which actually is not applicable for most real
applications. Instead, you probably will want to obtain the Model at some
other point, either in an event handler/command, during the beginDisplay()
method, or during the setRequestContext() method on the ViewBean (which
doubles as a something of an initialize method).
Todd
Guest at 2007-7-1 16:36:34 >
Hi Dennis--
> I have now added a SimpleTreeModel interface (which extends TreeModel) and
have added an
> mapping in ModelTypeMapImpl static initializer. i.e. To register
SimpleTreeModelImpl with the
> ModelManager.
This is fine, but you can so without the additional interface if you want.
You don't need to register the model in the ModelTypeMap, and you can
instead just pass the implementation class to ModelManager.
> In the tree view constructor instead of creating the SimpleTreeModelImpl
each time I use the
> ModelManager to retrieve the model, indicating that the model should be
stored in the sesssion:
>
> public Treeview(View parent, String name) {
> super(parent, name);
>
> RequestContext requestContext = getRequestContext();
> ModelManager modelManager = requestContext.getModelManager();
> Class clazz = SimpleTreeModel.class;
> SimpleTreeModel simpleTreeModel =
> (SimpleTreeModel)modelManager.getModel( clazz,
clazz.getName(), true, true );
>
> setPrimaryModel( simpleTreeModel );
> registerChildren();
> }
This looks good, EXCEPT for the fact that you shouldn't be able to get the
RequestContext at this point via the class's getRequestContext() method (it
isn't set until after the constructor). However, you can use the static
method RequestManager.getRequestContext() instead.
> The final bit I need to implement is the model creation on-demand.
Currently the entire model
> is constructed on the first access and stored in the session. However,
when model is large then
> this has a performance impact on constructing it for the first time.
Instead I would like to
> construct peices of the model as the user accesses them. Any ideas?
This is really a function of your model implementation. Nodes that are not
needed in a particular rendering of a TreeModel are never accessed by the
framework in that rendering, so you need to implement your model to lazily
fetch sub-trees of the underlying data structure only as needed. Depending
on the technology you are using, this may or may not be difficult.
I suspect that right now you are fetching the entire tree data structure
when the model is created, and this is the root of the problem. You need to
fetch all nodes that are children of the root on the first request, then
fetch child nodes of the next node the user expands on the next request, ad
infinitum. Otherwise, you will have to settle for a one-time performance
hit per session caused by retrieving the entire tree data structure at once.
If you are using TreeModelBase as your superclass and just implementing the
abstract methods therein, then the implementation of the firstChild() method
is your opportunity to fetch the tree data lazily. This method will be
called on a node to "step down" one level in the tree, and it will only be
called for the nodes that are expanded. You should implement this method to
figure out what node the model is on at the moment, then use that
information to determine if you've already looked up that node's childre in
the backend system, or if you need to go and fetch ONLY the current node's
direct children. As the user descends through the tree, the tree will be
fleshed out and cached lazily, one level at a time, via this mechanism.
Does this make any sense?
Todd
Guest at 2007-7-1 16:36:34 >
Thanks Todd,
That makes perfect sense.
Regards,
Dennis parrott.
Todd Fast wrote:
> Hi Dennis--
>
> > I have now added a SimpleTreeModel interface (which extends TreeModel) and
> have added an
> > mapping in ModelTypeMapImpl static initializer. i.e. To register
> SimpleTreeModelImpl with the
> > ModelManager.
>
> This is fine, but you can so without the additional interface if you want.
> You don't need to register the model in the ModelTypeMap, and you can
> instead just pass the implementation class to ModelManager.
>
> > In the tree view constructor instead of creating the SimpleTreeModelImpl
> each time I use the
> > ModelManager to retrieve the model, indicating that the model should be
> stored in the sesssion:
> >
> > public Treeview(View parent, String name) {
> > super(parent, name);
> >
> > RequestContext requestContext = getRequestContext();
> > ModelManager modelManager = requestContext.getModelManager();
> > Class clazz = SimpleTreeModel.class;
> > SimpleTreeModel simpleTreeModel =
> > (SimpleTreeModel)modelManager.getModel( clazz,
> clazz.getName(), true, true );
> >
> > setPrimaryModel( simpleTreeModel );
> > registerChildren();
> > }
>
> This looks good, EXCEPT for the fact that you shouldn't be able to get the
> RequestContext at this point via the class's getRequestContext() method (it
> isn't set until after the constructor). However, you can use the static
> method RequestManager.getRequestContext() instead.
>
> > The final bit I need to implement is the model creation on-demand.
> Currently the entire model
> > is constructed on the first access and stored in the session. However,
> when model is large then
> > this has a performance impact on constructing it for the first time.
> Instead I would like to
> > construct peices of the model as the user accesses them. Any ideas?
>
> This is really a function of your model implementation. Nodes that are not
> needed in a particular rendering of a TreeModel are never accessed by the
> framework in that rendering, so you need to implement your model to lazily
> fetch sub-trees of the underlying data structure only as needed. Depending
> on the technology you are using, this may or may not be difficult.
>
> I suspect that right now you are fetching the entire tree data structure
> when the model is created, and this is the root of the problem. You need to
> fetch all nodes that are children of the root on the first request, then
> fetch child nodes of the next node the user expands on the next request, ad
> infinitum. Otherwise, you will have to settle for a one-time performance
> hit per session caused by retrieving the entire tree data structure at once.
>
> If you are using TreeModelBase as your superclass and just implementing the
> abstract methods therein, then the implementation of the firstChild() method
> is your opportunity to fetch the tree data lazily. This method will be
> called on a node to "step down" one level in the tree, and it will only be
> called for the nodes that are expanded. You should implement this method to
> figure out what node the model is on at the moment, then use that
> information to determine if you've already looked up that node's childre in
> the backend system, or if you need to go and fetch ONLY the current node's
> direct children. As the user descends through the tree, the tree will be
> fleshed out and cached lazily, one level at a time, via this mechanism.
>
> Does this make any sense?
>
> Todd
>
>
> To download the latest version of S1AF (JATO), please visit one of the
following locations:
>
> Framework + IDE plugin for Sun ONE Studio 4 Update 1, Community Edition:
> <a href="http://wwws.sun.com/software/download/products/Appl_Frmwk_2.0_CE.html"> ;http://wwws.sun.com/software/download/products/Appl_Frmwk_2.0_CE.html</a>
>
> Framework + IDE pluign for Sun ONE Studio 4 Update 1, Enterprise Edition:
> <a href="http://wwws.sun.com/software/download/products/Appl_Frmwk_2.0_EE.html"> ;http://wwws.sun.com/software/download/products/Appl_Frmwk_2.0_EE.html</a>
>
> Previous versions of JATO:
> <a href="http://www.sun.com/software/download/developer/5102.html">http://www.s un.com/software/download/developer/5102.html</a>
>
>
[Non-text portions of this message have been removed]
Guest at 2007-7-1 16:36:34 >
