Home » Eclipse Projects » Eclipse Platform » lazy common navigator ?
| |
| Re: lazy common navigator ? [message #303451 is a reply to message #303171] |
Tue, 16 May 2006 01:54   |
 Michael D. Elder
Messages: 62
Registered: July 2009 |
Member |
|
|
Hi Max,
To clarify, there are two possible forms of lazy loading. One is the
support in JFace for ILazy*ContentProviders. Currently, the Common
Navigator framework does not support these types of content providers,
and this support is not planned.
The second form of lazy loading would involve asynchronously loading
your data and adding items to the tree in the background. As Michael
Valenta indicates, you can implement your own asynchronous loading
scheme whereby you would return some sort of "pending.." or "loading.."
node while you process the loading effort of the children. In the next
release, the Common Navigator framework *may* support this or make it
easier for clients to coordinate this type of behavior. For the 3.2 time
frame this feature was not containable.
There are clients (for instance in WTP) that implement the asynchronous
load of data. If you take a look at the J2EEContentProvider in
org.eclipse.jst.j2ee.navigator.ui (available from the Web Tools CVS
repo), you can see how this is done; a simple place holder node is
created and returned. Then a Job is started that handles the loading of
the J2EE deployment descriptor resource, which can incur network
communication to access schemas for XSD validation purposes. A second
UIJob is started that animates the placeholder node's icon and text (it
spins an arrow and replaces the text with running elipses ("...")). When
the loading Job completes, the UIJob detects this with a flag that is
shared between the two Jobs. Finally, a UIJob removes the pending node
and adds the node representing the loaded deployment descriptor. This
scheme can be generalized to 0...n elements, but here it's only used for
one element from the content provider (the deployment descriptor's
enhanced metamodel node in the tree).
HTH,
-MDE.
Max Rydahl Andersen wrote:
> Hi,
>
> Before I dive fully into porting my custom treeview's into the common
> navigator I would
> like to hear if there is some known issues or limitations within the
> common navigator API
> when it comes to provide *lazy* tree's ?
> (lazy as in "does not block ui when elements are loading" ?)
>
> Is it at all possible ?
>
> /max
|
|
|
| Re: lazy common navigator ? [message #303738 is a reply to message #303451] |
Sun, 21 May 2006 07:53 |
Max Rydahl Andersen
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
thanks for the tip...looks like common navigator might be usable for me
after all ;)
/max
> Hi Max,
>
> To clarify, there are two possible forms of lazy loading. One is the
> support in JFace for ILazy*ContentProviders. Currently, the Common
> Navigator framework does not support these types of content providers,
> and this support is not planned.
>
> The second form of lazy loading would involve asynchronously loading
> your data and adding items to the tree in the background. As Michael
> Valenta indicates, you can implement your own asynchronous loading
> scheme whereby you would return some sort of "pending.." or "loading.."
> node while you process the loading effort of the children. In the next
> release, the Common Navigator framework *may* support this or make it
> easier for clients to coordinate this type of behavior. For the 3.2 time
> frame this feature was not containable.
>
> There are clients (for instance in WTP) that implement the asynchronous
> load of data. If you take a look at the J2EEContentProvider in
> org.eclipse.jst.j2ee.navigator.ui (available from the Web Tools CVS
> repo), you can see how this is done; a simple place holder node is
> created and returned. Then a Job is started that handles the loading of
> the J2EE deployment descriptor resource, which can incur network
> communication to access schemas for XSD validation purposes. A second
> UIJob is started that animates the placeholder node's icon and text (it
> spins an arrow and replaces the text with running elipses ("...")). When
> the loading Job completes, the UIJob detects this with a flag that is
> shared between the two Jobs. Finally, a UIJob removes the pending node
> and adds the node representing the loaded deployment descriptor. This
> scheme can be generalized to 0...n elements, but here it's only used for
> one element from the content provider (the deployment descriptor's
> enhanced metamodel node in the tree).
>
> HTH,
>
> -MDE.
>
> Max Rydahl Andersen wrote:
>> Hi,
>> Before I dive fully into porting my custom treeview's into the common
>> navigator I would
>> like to hear if there is some known issues or limitations within the
>> common navigator API
>> when it comes to provide *lazy* tree's ?
>> (lazy as in "does not block ui when elements are loading" ?)
>> Is it at all possible ?
>> /max
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: lazy common navigator ? [message #303838 is a reply to message #303738] |
Wed, 24 May 2006 10:52 |
Max Rydahl Andersen
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
>
> thanks for the tip...looks like common navigator might be usable for me
> after all ;)
I just tried to adapt the mechanism used in J2EEContentProvider and it
does not really work since it add nodes *directly* to the treeviewer
making it lookup a contentprovider via possibleChildren instead of using
the contentProvider it came from. This is both a performance and
semantically
bad thing for me since I would have children that are of the same type but
will be interpreted differently by different contentProviders.
Is there any alternative way of doing the lazy things ? (possibly somehow
to tell the common contentprovider that *this* contentprovider is what
should
be used for these added children)
/max
> /max
>
>> Hi Max,
>>
>> To clarify, there are two possible forms of lazy loading. One is the
>> support in JFace for ILazy*ContentProviders. Currently, the Common
>> Navigator framework does not support these types of content providers,
>> and this support is not planned.
>>
>> The second form of lazy loading would involve asynchronously loading
>> your data and adding items to the tree in the background. As Michael
>> Valenta indicates, you can implement your own asynchronous loading
>> scheme whereby you would return some sort of "pending.." or "loading.."
>> node while you process the loading effort of the children. In the next
>> release, the Common Navigator framework *may* support this or make it
>> easier for clients to coordinate this type of behavior. For the 3.2
>> time frame this feature was not containable.
>>
>> There are clients (for instance in WTP) that implement the
>> asynchronous load of data. If you take a look at the
>> J2EEContentProvider in org.eclipse.jst.j2ee.navigator.ui (available
>> from the Web Tools CVS repo), you can see how this is done; a simple
>> place holder node is created and returned. Then a Job is started that
>> handles the loading of the J2EE deployment descriptor resource, which
>> can incur network communication to access schemas for XSD validation
>> purposes. A second UIJob is started that animates the placeholder
>> node's icon and text (it spins an arrow and replaces the text with
>> running elipses ("...")). When the loading Job completes, the UIJob
>> detects this with a flag that is shared between the two Jobs. Finally,
>> a UIJob removes the pending node and adds the node representing the
>> loaded deployment descriptor. This scheme can be generalized to 0...n
>> elements, but here it's only used for one element from the content
>> provider (the deployment descriptor's enhanced metamodel node in the
>> tree).
>>
>> HTH,
>>
>> -MDE.
>>
>> Max Rydahl Andersen wrote:
>>> Hi,
>>> Before I dive fully into porting my custom treeview's into the common
>>> navigator I would
>>> like to hear if there is some known issues or limitations within the
>>> common navigator API
>>> when it comes to provide *lazy* tree's ?
>>> (lazy as in "does not block ui when elements are loading" ?)
>>> Is it at all possible ?
>>> /max
>
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: lazy common navigator ? [message #304000 is a reply to message #303838] |
Sat, 27 May 2006 22:30 |
Michael D. Elder
Messages: 62
Registered: July 2009 |
Member |
|
|
Hi Max,
There is no way to tell the framework through public API. You would have
to access NavigatorContentService.rememberContribution() to get that
kind of behavior. Using that method (which is currently not supported
API) must be done at your own risk.
For the J2EE provider case, it has a model that is specific to it. Yours
is the first case I've heard of where there is more than one content
provider for the same model where each wants to render the model
elements differently. Even in the Java/Resource case, each content
extension wants to render their shared model the same (an IFolder is an
IFolder with the same label and icon regardless of which one wins).
One thing you might consider doing is defining a property tester
(org.eclipse.core.expression.propertyTester), enabled on your Model
Element Type, that would test for a "tag" (perhaps the id of your
content extensions?). The solution might look something like this:
Each content provider "tags" a model element when returning it. You'll
need to decide what "tags" means. Maybe you store it in a WeakHashMap
per content provider, or maybe you add an EMF Adapter to the element
related the content provider (One EMF adapter per content provider? Or
even the content provider itself?).
Then in your content extensions, you define an expression which includes
the property tester; perhaps specifying the id of the content extension
as the "value". The property tester would be able to accept model
elements and test them for the id in the expression. This would allow
you to correlate model elements with the content provider responsible
for rendering them.
Now when the framework searches for a matching content extension, the
property tester would provide you with more robust filtering than the
CNF's ability to remember the source of the item.
You'll need to consider the potential performance impact of a solution
like this for your scenarios. I think if done properly, the robustness
of the solution would be worth the small performance penalty.
You should also be aware that the CNF uses a cache based on the
evaluation of the expressions for which extensions are interested in an
element. So there's an implicit requirement that an extension may not
change whether it is interested in an element dynamically (as there's no
public way to flush the cache). Therefore, if you use a solution like
this, then the same content extension *must always* be the one that will
always be interested in rendering it. There was no use case to support
the set of content extensions interested in an element to be changed
dynamically, and consequently the CNF doesn't support it. This may or
may not be an issue in your scenario.
-MDE.
Max Rydahl Andersen wrote:
>
>>
>> thanks for the tip...looks like common navigator might be usable for
>> me after all ;)
>
> I just tried to adapt the mechanism used in J2EEContentProvider and it
> does not really work since it add nodes *directly* to the treeviewer
> making it lookup a contentprovider via possibleChildren instead of using
> the contentProvider it came from. This is both a performance and
> semantically
> bad thing for me since I would have children that are of the same type but
> will be interpreted differently by different contentProviders.
>
> Is there any alternative way of doing the lazy things ? (possibly somehow
> to tell the common contentprovider that *this* contentprovider is what
> should
> be used for these added children)
>
> /max
>
>> /max
>>
>>> Hi Max,
>>>
>>> To clarify, there are two possible forms of lazy loading. One is
>>> the support in JFace for ILazy*ContentProviders. Currently, the
>>> Common Navigator framework does not support these types of content
>>> providers, and this support is not planned.
>>>
>>> The second form of lazy loading would involve asynchronously
>>> loading your data and adding items to the tree in the background. As
>>> Michael Valenta indicates, you can implement your own asynchronous
>>> loading scheme whereby you would return some sort of "pending.." or
>>> "loading.." node while you process the loading effort of the
>>> children. In the next release, the Common Navigator framework *may*
>>> support this or make it easier for clients to coordinate this type of
>>> behavior. For the 3.2 time frame this feature was not containable.
>>>
>>> There are clients (for instance in WTP) that implement the
>>> asynchronous load of data. If you take a look at the
>>> J2EEContentProvider in org.eclipse.jst.j2ee.navigator.ui
>>> (available from the Web Tools CVS repo), you can see how this is
>>> done; a simple place holder node is created and returned. Then a Job
>>> is started that handles the loading of the J2EE deployment descriptor
>>> resource, which can incur network communication to access schemas for
>>> XSD validation purposes. A second UIJob is started that animates the
>>> placeholder node's icon and text (it spins an arrow and replaces the
>>> text with running elipses ("...")). When the loading Job completes,
>>> the UIJob detects this with a flag that is shared between the two
>>> Jobs. Finally, a UIJob removes the pending node and adds the node
>>> representing the loaded deployment descriptor. This scheme can be
>>> generalized to 0...n elements, but here it's only used for one
>>> element from the content provider (the deployment descriptor's
>>> enhanced metamodel node in the tree).
>>>
>>> HTH,
>>>
>>> -MDE.
>>>
>>> Max Rydahl Andersen wrote:
>>>> Hi,
>>>> Before I dive fully into porting my custom treeview's into the
>>>> common navigator I would
>>>> like to hear if there is some known issues or limitations within the
>>>> common navigator API
>>>> when it comes to provide *lazy* tree's ?
>>>> (lazy as in "does not block ui when elements are loading" ?)
>>>> Is it at all possible ?
>>>> /max
>>
>>
>>
>
>
>
> --Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: lazy common navigator ? [message #304039 is a reply to message #304000] |
Mon, 29 May 2006 12:15 |
Max Rydahl Andersen
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
> There is no way to tell the framework through public API. You would have
> to access NavigatorContentService.rememberContribution() to get that
> kind of behavior. Using that method (which is currently not supported
> API) must be done at your own risk.
ok - but how do I get to the correct NavigatorContentService ?
> For the J2EE provider case, it has a model that is specific to it. Yours
> is the first case I've heard of where there is more than one content
> provider for the same model where each wants to render the model
> elements differently.
It's not so much a "more than one content provider", it is more a problem
of:
a) not wanting the performance hit of evaluating/looking up the content
provider since it should
just take the one that provided it (which is actually the default way of
doing things if I read the code
correctly)
b) not knowing what the children will be like, besides them being instance
of Object.
(one part of the viewer is showing an object graph and I don't feel like
nesting that inside
yet another model if I really have to.)
c) not having to rewrite existing contentproviders/label providers to
support yet another way of loading things lazily.
> One thing you might consider doing is defining a property tester
> (org.eclipse.core.expression.propertyTester), enabled on your Model
> Element Type, that would test for a "tag" (perhaps the id of your
> content extensions?). The solution might look something like this:
Only works if you actually have a common type.
/max
>
> Each content provider "tags" a model element when returning it. You'll
> need to decide what "tags" means. Maybe you store it in a WeakHashMap
> per content provider, or maybe you add an EMF Adapter to the element
> related the content provider (One EMF adapter per content provider? Or
> even the content provider itself?).
>
> Then in your content extensions, you define an expression which includes
> the property tester; perhaps specifying the id of the content extension
> as the "value". The property tester would be able to accept model
> elements and test them for the id in the expression. This would allow
> you to correlate model elements with the content provider responsible
> for rendering them.
>
> Now when the framework searches for a matching content extension, the
> property tester would provide you with more robust filtering than the
> CNF's ability to remember the source of the item.
>
> You'll need to consider the potential performance impact of a solution
> like this for your scenarios. I think if done properly, the robustness
> of the solution would be worth the small performance penalty.
>
> You should also be aware that the CNF uses a cache based on the
> evaluation of the expressions for which extensions are interested in an
> element. So there's an implicit requirement that an extension may not
> change whether it is interested in an element dynamically (as there's no
> public way to flush the cache). Therefore, if you use a solution like
> this, then the same content extension *must always* be the one that will
> always be interested in rendering it. There was no use case to support
> the set of content extensions interested in an element to be changed
> dynamically, and consequently the CNF doesn't support it. This may or
> may not be an issue in your scenario.
>
> -MDE.
>
> Max Rydahl Andersen wrote:
>>
>>>
>>> thanks for the tip...looks like common navigator might be usable for
>>> me after all ;)
>> I just tried to adapt the mechanism used in J2EEContentProvider and it
>> does not really work since it add nodes *directly* to the treeviewer
>> making it lookup a contentprovider via possibleChildren instead of using
>> the contentProvider it came from. This is both a performance and
>> semantically
>> bad thing for me since I would have children that are of the same type
>> but
>> will be interpreted differently by different contentProviders.
>> Is there any alternative way of doing the lazy things ? (possibly
>> somehow
>> to tell the common contentprovider that *this* contentprovider is what
>> should
>> be used for these added children)
>> /max
>>
>>> /max
>>>
>>>> Hi Max,
>>>>
>>>> To clarify, there are two possible forms of lazy loading. One is
>>>> the support in JFace for ILazy*ContentProviders. Currently, the
>>>> Common Navigator framework does not support these types of content
>>>> providers, and this support is not planned.
>>>>
>>>> The second form of lazy loading would involve asynchronously
>>>> loading your data and adding items to the tree in the background. As
>>>> Michael Valenta indicates, you can implement your own asynchronous
>>>> loading scheme whereby you would return some sort of "pending.." or
>>>> "loading.." node while you process the loading effort of the
>>>> children. In the next release, the Common Navigator framework *may*
>>>> support this or make it easier for clients to coordinate this type of
>>>> behavior. For the 3.2 time frame this feature was not containable.
>>>>
>>>> There are clients (for instance in WTP) that implement the
>>>> asynchronous load of data. If you take a look at the
>>>> J2EEContentProvider in org.eclipse.jst.j2ee.navigator.ui
>>>> (available from the Web Tools CVS repo), you can see how this is
>>>> done; a simple place holder node is created and returned. Then a Job
>>>> is started that handles the loading of the J2EE deployment descriptor
>>>> resource, which can incur network communication to access schemas for
>>>> XSD validation purposes. A second UIJob is started that animates the
>>>> placeholder node's icon and text (it spins an arrow and replaces the
>>>> text with running elipses ("...")). When the loading Job completes,
>>>> the UIJob detects this with a flag that is shared between the two
>>>> Jobs. Finally, a UIJob removes the pending node and adds the node
>>>> representing the loaded deployment descriptor. This scheme can be
>>>> generalized to 0...n elements, but here it's only used for one
>>>> element from the content provider (the deployment descriptor's
>>>> enhanced metamodel node in the tree).
>>>>
>>>> HTH,
>>>>
>>>> -MDE.
>>>>
>>>> Max Rydahl Andersen wrote:
>>>>> Hi,
>>>>> Before I dive fully into porting my custom treeview's into the
>>>>> common navigator I would
>>>>> like to hear if there is some known issues or limitations within the
>>>>> common navigator API
>>>>> when it comes to provide *lazy* tree's ?
>>>>> (lazy as in "does not block ui when elements are loading" ?)
>>>>> Is it at all possible ?
>>>>> /max
>>>
>>>
>>>
>> --Using Opera's revolutionary e-mail client:
>> http://www.opera.com/mail/
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: lazy common navigator ? [message #304063 is a reply to message #304039] |
Mon, 29 May 2006 19:36 |
Max Rydahl Andersen
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
btw. using a contentprovider that delegates to my existing
DeferredContentProvider + IDeferredWorkbenchAdapter in the nodes seem
to give me "automatic" lazy behavior IFF I also do a (from my view
redundant) possibleChildren declaration.
>
>> There is no way to tell the framework through public API. You would
>> have to access NavigatorContentService.rememberContribution() to get
>> that kind of behavior. Using that method (which is currently not
>> supported API) must be done at your own risk.
>
> ok - but how do I get to the correct NavigatorContentService ?
>
>> For the J2EE provider case, it has a model that is specific to it.
>> Yours is the first case I've heard of where there is more than one
>> content provider for the same model where each wants to render the
>> model elements differently.
>
> It's not so much a "more than one content provider", it is more a problem
> of:
>
> a) not wanting the performance hit of evaluating/looking up the content
> provider since it should
> just take the one that provided it (which is actually the default way of
> doing things if I read the code
> correctly)
>
> b) not knowing what the children will be like, besides them being
> instance of Object.
> (one part of the viewer is showing an object graph and I don't feel like
> nesting that inside
> yet another model if I really have to.)
>
> c) not having to rewrite existing contentproviders/label providers to
> support yet another way of loading things lazily.
>
>> One thing you might consider doing is defining a property tester
>> (org.eclipse.core.expression.propertyTester), enabled on your Model
>> Element Type, that would test for a "tag" (perhaps the id of your
>> content extensions?). The solution might look something like this:
>
> Only works if you actually have a common type.
>
> /max
>
>>
>> Each content provider "tags" a model element when returning it. You'll
>> need to decide what "tags" means. Maybe you store it in a WeakHashMap
>> per content provider, or maybe you add an EMF Adapter to the element
>> related the content provider (One EMF adapter per content provider? Or
>> even the content provider itself?).
>>
>> Then in your content extensions, you define an expression which
>> includes the property tester; perhaps specifying the id of the content
>> extension as the "value". The property tester would be able to accept
>> model elements and test them for the id in the expression. This would
>> allow you to correlate model elements with the content provider
>> responsible for rendering them.
>>
>> Now when the framework searches for a matching content extension, the
>> property tester would provide you with more robust filtering than the
>> CNF's ability to remember the source of the item.
>>
>> You'll need to consider the potential performance impact of a solution
>> like this for your scenarios. I think if done properly, the robustness
>> of the solution would be worth the small performance penalty.
>>
>> You should also be aware that the CNF uses a cache based on the
>> evaluation of the expressions for which extensions are interested in an
>> element. So there's an implicit requirement that an extension may not
>> change whether it is interested in an element dynamically (as there's
>> no public way to flush the cache). Therefore, if you use a solution
>> like this, then the same content extension *must always* be the one
>> that will always be interested in rendering it. There was no use case
>> to support the set of content extensions interested in an element to be
>> changed dynamically, and consequently the CNF doesn't support it. This
>> may or may not be an issue in your scenario.
>>
>> -MDE.
>>
>> Max Rydahl Andersen wrote:
>>>
>>>>
>>>> thanks for the tip...looks like common navigator might be usable for
>>>> me after all ;)
>>> I just tried to adapt the mechanism used in J2EEContentProvider and it
>>> does not really work since it add nodes *directly* to the treeviewer
>>> making it lookup a contentprovider via possibleChildren instead of
>>> using
>>> the contentProvider it came from. This is both a performance and
>>> semantically
>>> bad thing for me since I would have children that are of the same type
>>> but
>>> will be interpreted differently by different contentProviders.
>>> Is there any alternative way of doing the lazy things ? (possibly
>>> somehow
>>> to tell the common contentprovider that *this* contentprovider is what
>>> should
>>> be used for these added children)
>>> /max
>>>
>>>> /max
>>>>
>>>>> Hi Max,
>>>>>
>>>>> To clarify, there are two possible forms of lazy loading. One is
>>>>> the support in JFace for ILazy*ContentProviders. Currently, the
>>>>> Common Navigator framework does not support these types of content
>>>>> providers, and this support is not planned.
>>>>>
>>>>> The second form of lazy loading would involve asynchronously
>>>>> loading your data and adding items to the tree in the background. As
>>>>> Michael Valenta indicates, you can implement your own asynchronous
>>>>> loading scheme whereby you would return some sort of "pending.." or
>>>>> "loading.." node while you process the loading effort of the
>>>>> children. In the next release, the Common Navigator framework *may*
>>>>> support this or make it easier for clients to coordinate this type
>>>>> of behavior. For the 3.2 time frame this feature was not containable.
>>>>>
>>>>> There are clients (for instance in WTP) that implement the
>>>>> asynchronous load of data. If you take a look at the
>>>>> J2EEContentProvider in org.eclipse.jst.j2ee.navigator.ui
>>>>> (available from the Web Tools CVS repo), you can see how this is
>>>>> done; a simple place holder node is created and returned. Then a Job
>>>>> is started that handles the loading of the J2EE deployment
>>>>> descriptor resource, which can incur network communication to access
>>>>> schemas for XSD validation purposes. A second UIJob is started that
>>>>> animates the placeholder node's icon and text (it spins an arrow and
>>>>> replaces the text with running elipses ("...")). When the loading
>>>>> Job completes, the UIJob detects this with a flag that is shared
>>>>> between the two Jobs. Finally, a UIJob removes the pending node and
>>>>> adds the node representing the loaded deployment descriptor. This
>>>>> scheme can be generalized to 0...n elements, but here it's only used
>>>>> for one element from the content provider (the deployment
>>>>> descriptor's enhanced metamodel node in the tree).
>>>>>
>>>>> HTH,
>>>>>
>>>>> -MDE.
>>>>>
>>>>> Max Rydahl Andersen wrote:
>>>>>> Hi,
>>>>>> Before I dive fully into porting my custom treeview's into the
>>>>>> common navigator I would
>>>>>> like to hear if there is some known issues or limitations within
>>>>>> the common navigator API
>>>>>> when it comes to provide *lazy* tree's ?
>>>>>> (lazy as in "does not block ui when elements are loading" ?)
>>>>>> Is it at all possible ?
>>>>>> /max
>>>>
>>>>
>>>>
>>> --Using Opera's revolutionary e-mail client:
>>> http://www.opera.com/mail/
>
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: lazy common navigator ? [message #304097 is a reply to message #304063] |
Tue, 30 May 2006 17:34 |
Michael D. Elder
Messages: 62
Registered: July 2009 |
Member |
|
|
Hi Max,
The declaration in the possibleChildren expression is required since
without it, the framework has no way of knowing what you *may*
contribute. If you ever want link with editor or set selection to work
reliably, you must specify the possibleChildren expression as accurately
as possible. Each extension is only loaded if needed. Therefore, if
you're extension isn't loaded, or hasn't contributed an item yet, then
the framework can't use your content provider to establish a correct
parent.
You can get to the content service through the CommonViewer. If you have
the viewer in the content provider, and it's an instance of
CommonViewer, you can call getNavigatorContentService().
Are you not aware of what model the content provider is rendering? Why
are you unsure what the type is other than Object? Can you provide a
little more information about your use case? All other content providers
I'm aware of know what their model looks like -- at least the types of
objects that can be returned. This is true for EMF and non-EMF based
models.
Can you enumerate the pieces of the existing content/label providers
that require or might require a re-write to integrate with the framework?
-MDE.
Max Rydahl Andersen wrote:
>
> btw. using a contentprovider that delegates to my existing
> DeferredContentProvider + IDeferredWorkbenchAdapter in the nodes seem
> to give me "automatic" lazy behavior IFF I also do a (from my view
> redundant) possibleChildren declaration.
>
>>
>>> There is no way to tell the framework through public API. You would
>>> have to access NavigatorContentService.rememberContribution() to get
>>> that kind of behavior. Using that method (which is currently not
>>> supported API) must be done at your own risk.
>>
>> ok - but how do I get to the correct NavigatorContentService ?
>>
>>> For the J2EE provider case, it has a model that is specific to it.
>>> Yours is the first case I've heard of where there is more than one
>>> content provider for the same model where each wants to render the
>>> model elements differently.
>>
>> It's not so much a "more than one content provider", it is more a problem
>> of:
>>
>> a) not wanting the performance hit of evaluating/looking up the
>> content provider since it should
>> just take the one that provided it (which is actually the default way
>> of doing things if I read the code
>> correctly)
>>
>> b) not knowing what the children will be like, besides them being
>> instance of Object.
>> (one part of the viewer is showing an object graph and I don't feel
>> like nesting that inside
>> yet another model if I really have to.)
>>
>> c) not having to rewrite existing contentproviders/label providers to
>> support yet another way of loading things lazily.
>>
>>> One thing you might consider doing is defining a property tester
>>> (org.eclipse.core.expression.propertyTester), enabled on your Model
>>> Element Type, that would test for a "tag" (perhaps the id of your
>>> content extensions?). The solution might look something like this:
>>
>> Only works if you actually have a common type.
>>
>> /max
>>
>>>
>>> Each content provider "tags" a model element when returning it.
>>> You'll need to decide what "tags" means. Maybe you store it in a
>>> WeakHashMap per content provider, or maybe you add an EMF Adapter to
>>> the element related the content provider (One EMF adapter per content
>>> provider? Or even the content provider itself?).
>>>
>>> Then in your content extensions, you define an expression which
>>> includes the property tester; perhaps specifying the id of the
>>> content extension as the "value". The property tester would be able
>>> to accept model elements and test them for the id in the expression.
>>> This would allow you to correlate model elements with the content
>>> provider responsible for rendering them.
>>>
>>> Now when the framework searches for a matching content extension, the
>>> property tester would provide you with more robust filtering than the
>>> CNF's ability to remember the source of the item.
>>>
>>> You'll need to consider the potential performance impact of a
>>> solution like this for your scenarios. I think if done properly, the
>>> robustness of the solution would be worth the small performance penalty.
>>>
>>> You should also be aware that the CNF uses a cache based on the
>>> evaluation of the expressions for which extensions are interested in
>>> an element. So there's an implicit requirement that an extension may
>>> not change whether it is interested in an element dynamically (as
>>> there's no public way to flush the cache). Therefore, if you use a
>>> solution like this, then the same content extension *must always* be
>>> the one that will always be interested in rendering it. There was no
>>> use case to support the set of content extensions interested in an
>>> element to be changed dynamically, and consequently the CNF doesn't
>>> support it. This may or may not be an issue in your scenario.
>>>
>>> -MDE.
>>>
>>> Max Rydahl Andersen wrote:
>>>>
>>>>>
>>>>> thanks for the tip...looks like common navigator might be usable
>>>>> for me after all ;)
>>>> I just tried to adapt the mechanism used in J2EEContentProvider and it
>>>> does not really work since it add nodes *directly* to the treeviewer
>>>> making it lookup a contentprovider via possibleChildren instead of
>>>> using
>>>> the contentProvider it came from. This is both a performance and
>>>> semantically
>>>> bad thing for me since I would have children that are of the same
>>>> type but
>>>> will be interpreted differently by different contentProviders.
>>>> Is there any alternative way of doing the lazy things ? (possibly
>>>> somehow
>>>> to tell the common contentprovider that *this* contentprovider is
>>>> what should
>>>> be used for these added children)
>>>> /max
>>>>
>>>>> /max
>>>>>
>>>>>> Hi Max,
>>>>>>
>>>>>> To clarify, there are two possible forms of lazy loading. One
>>>>>> is the support in JFace for ILazy*ContentProviders. Currently, the
>>>>>> Common Navigator framework does not support these types of content
>>>>>> providers, and this support is not planned.
>>>>>>
>>>>>> The second form of lazy loading would involve asynchronously
>>>>>> loading your data and adding items to the tree in the background.
>>>>>> As Michael Valenta indicates, you can implement your own
>>>>>> asynchronous loading scheme whereby you would return some sort of
>>>>>> "pending.." or "loading.." node while you process the loading
>>>>>> effort of the children. In the next release, the Common Navigator
>>>>>> framework *may* support this or make it easier for clients to
>>>>>> coordinate this type of behavior. For the 3.2 time frame this
>>>>>> feature was not containable.
>>>>>>
>>>>>> There are clients (for instance in WTP) that implement the
>>>>>> asynchronous load of data. If you take a look at the
>>>>>> J2EEContentProvider in org.eclipse.jst.j2ee.navigator.ui
>>>>>> (available from the Web Tools CVS repo), you can see how this is
>>>>>> done; a simple place holder node is created and returned. Then a
>>>>>> Job is started that handles the loading of the J2EE deployment
>>>>>> descriptor resource, which can incur network communication to
>>>>>> access schemas for XSD validation purposes. A second UIJob is
>>>>>> started that animates the placeholder node's icon and text (it
>>>>>> spins an arrow and replaces the text with running elipses
>>>>>> ("...")). When the loading Job completes, the UIJob detects this
>>>>>> with a flag that is shared between the two Jobs. Finally, a UIJob
>>>>>> removes the pending node and adds the node representing the loaded
>>>>>> deployment descriptor. This scheme can be generalized to 0...n
>>>>>> elements, but here it's only used for one element from the content
>>>>>> provider (the deployment descriptor's enhanced metamodel node in
>>>>>> the tree).
>>>>>>
>>>>>> HTH,
>>>>>>
>>>>>> -MDE.
>>>>>>
>>>>>> Max Rydahl Andersen wrote:
>>>>>>> Hi,
>>>>>>> Before I dive fully into porting my custom treeview's into the
>>>>>>> common navigator I would
>>>>>>> like to hear if there is some known issues or limitations within
>>>>>>> the common navigator API
>>>>>>> when it comes to provide *lazy* tree's ?
>>>>>>> (lazy as in "does not block ui when elements are loading" ?)
>>>>>>> Is it at all possible ?
>>>>>>> /max
>>>>>
>>>>>
>>>>>
>>>> --Using Opera's revolutionary e-mail client:
>>>> http://www.opera.com/mail/
>>
>>
>>
>
>
>
> --Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: lazy common navigator ? [message #304181 is a reply to message #304063] |
Fri, 02 June 2006 06:44 |
Max Rydahl Andersen
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
I can't remember if I answered this part, so here it comes.
> Are you not aware of what model the content provider is rendering? Why
> are you unsure what the type is other than Object? Can you provide a
> little
> more information about your use case?
My case is that one of the subtree's I have is a result of EJB3 query
against a database. That result is an arbitrary object graph, hence I don't
know the node type (unless I rewrap it into a shadow model)....and some of
the children of these nodes my take a while to return hence my wish for
lazy loading it and somehow let the content service know that a certain
contentprovider should be used for this root object and downwards.
But I guess I'll simply need to create a shadow model; just feels so wrong
to constantly having to double the number of modelui objects just to
"please" SWT/JFace way of doing things ;(
/max
>
> btw. using a contentprovider that delegates to my existing
> DeferredContentProvider + IDeferredWorkbenchAdapter in the nodes seem
> to give me "automatic" lazy behavior IFF I also do a (from my view
> redundant) possibleChildren declaration.
>
>>
>>> There is no way to tell the framework through public API. You would
>>> have to access NavigatorContentService.rememberContribution() to get
>>> that kind of behavior. Using that method (which is currently not
>>> supported API) must be done at your own risk.
>>
>> ok - but how do I get to the correct NavigatorContentService ?
>>
>>> For the J2EE provider case, it has a model that is specific to it.
>>> Yours is the first case I've heard of where there is more than one
>>> content provider for the same model where each wants to render the
>>> model elements differently.
>>
>> It's not so much a "more than one content provider", it is more a
>> problem
>> of:
>>
>> a) not wanting the performance hit of evaluating/looking up the content
>> provider since it should
>> just take the one that provided it (which is actually the default way
>> of doing things if I read the code
>> correctly)
>>
>> b) not knowing what the children will be like, besides them being
>> instance of Object.
>> (one part of the viewer is showing an object graph and I don't feel
>> like nesting that inside
>> yet another model if I really have to.)
>>
>> c) not having to rewrite existing contentproviders/label providers to
>> support yet another way of loading things lazily.
>>
>>> One thing you might consider doing is defining a property tester
>>> (org.eclipse.core.expression.propertyTester), enabled on your Model
>>> Element Type, that would test for a "tag" (perhaps the id of your
>>> content extensions?). The solution might look something like this:
>>
>> Only works if you actually have a common type.
>>
>> /max
>>
>>>
>>> Each content provider "tags" a model element when returning it. You'll
>>> need to decide what "tags" means. Maybe you store it in a WeakHashMap
>>> per content provider, or maybe you add an EMF Adapter to the element
>>> related the content provider (One EMF adapter per content provider? Or
>>> even the content provider itself?).
>>>
>>> Then in your content extensions, you define an expression which
>>> includes the property tester; perhaps specifying the id of the content
>>> extension as the "value". The property tester would be able to accept
>>> model elements and test them for the id in the expression. This would
>>> allow you to correlate model elements with the content provider
>>> responsible for rendering them.
>>>
>>> Now when the framework searches for a matching content extension, the
>>> property tester would provide you with more robust filtering than the
>>> CNF's ability to remember the source of the item.
>>>
>>> You'll need to consider the potential performance impact of a solution
>>> like this for your scenarios. I think if done properly, the robustness
>>> of the solution would be worth the small performance penalty.
>>>
>>> You should also be aware that the CNF uses a cache based on the
>>> evaluation of the expressions for which extensions are interested in
>>> an element. So there's an implicit requirement that an extension may
>>> not change whether it is interested in an element dynamically (as
>>> there's no public way to flush the cache). Therefore, if you use a
>>> solution like this, then the same content extension *must always* be
>>> the one that will always be interested in rendering it. There was no
>>> use case to support the set of content extensions interested in an
>>> element to be changed dynamically, and consequently the CNF doesn't
>>> support it. This may or may not be an issue in your scenario.
>>>
>>> -MDE.
>>>
>>> Max Rydahl Andersen wrote:
>>>>
>>>>>
>>>>> thanks for the tip...looks like common navigator might be usable for
>>>>> me after all ;)
>>>> I just tried to adapt the mechanism used in J2EEContentProvider and
>>>> it
>>>> does not really work since it add nodes *directly* to the treeviewer
>>>> making it lookup a contentprovider via possibleChildren instead of
>>>> using
>>>> the contentProvider it came from. This is both a performance and
>>>> semantically
>>>> bad thing for me since I would have children that are of the same
>>>> type but
>>>> will be interpreted differently by different contentProviders.
>>>> Is there any alternative way of doing the lazy things ? (possibly
>>>> somehow
>>>> to tell the common contentprovider that *this* contentprovider is
>>>> what should
>>>> be used for these added children)
>>>> /max
>>>>
>>>>> /max
>>>>>
>>>>>> Hi Max,
>>>>>>
>>>>>> To clarify, there are two possible forms of lazy loading. One
>>>>>> is the support in JFace for ILazy*ContentProviders. Currently, the
>>>>>> Common Navigator framework does not support these types of content
>>>>>> providers, and this support is not planned.
>>>>>>
>>>>>> The second form of lazy loading would involve asynchronously
>>>>>> loading your data and adding items to the tree in the background.
>>>>>> As Michael Valenta indicates, you can implement your own
>>>>>> asynchronous loading scheme whereby you would return some sort of
>>>>>> "pending.." or "loading.." node while you process the loading
>>>>>> effort of the children. In the next release, the Common Navigator
>>>>>> framework *may* support this or make it easier for clients to
>>>>>> coordinate this type of behavior. For the 3.2 time frame this
>>>>>> feature was not containable.
>>>>>>
>>>>>> There are clients (for instance in WTP) that implement the
>>>>>> asynchronous load of data. If you take a look at the
>>>>>> J2EEContentProvider in org.eclipse.jst.j2ee.navigator.ui
>>>>>> (available from the Web Tools CVS repo), you can see how this is
>>>>>> done; a simple place holder node is created and returned. Then a
>>>>>> Job is started that handles the loading of the J2EE deployment
>>>>>> descriptor resource, which can incur network communication to
>>>>>> access schemas for XSD validation purposes. A second UIJob is
>>>>>> started that animates the placeholder node's icon and text (it
>>>>>> spins an arrow and replaces the text with running elipses ("...")).
>>>>>> When the loading Job completes, the UIJob detects this with a flag
>>>>>> that is shared between the two Jobs. Finally, a UIJob removes the
>>>>>> pending node and adds the node representing the loaded deployment
>>>>>> descriptor. This scheme can be generalized to 0...n elements, but
>>>>>> here it's only used for one element from the content provider (the
>>>>>> deployment descriptor's enhanced metamodel node in the tree).
>>>>>>
>>>>>> HTH,
>>>>>>
>>>>>> -MDE.
>>>>>>
>>>>>> Max Rydahl Andersen wrote:
>>>>>>> Hi,
>>>>>>> Before I dive fully into porting my custom treeview's into the
>>>>>>> common navigator I would
>>>>>>> like to hear if there is some known issues or limitations within
>>>>>>> the common navigator API
>>>>>>> when it comes to provide *lazy* tree's ?
>>>>>>> (lazy as in "does not block ui when elements are loading" ?)
>>>>>>> Is it at all possible ?
>>>>>>> /max
>>>>>
>>>>>
>>>>>
>>>> --Using Opera's revolutionary e-mail client:
>>>> http://www.opera.com/mail/
>>
>>
>>
>
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
| |
Goto Forum:
Current Time: Fri Apr 26 07:13:27 GMT 2024
Powered by FUDForum. Page generated in 0.03952 seconds |
] 
Search
Help
Register
Login
Home
