Hi Christian
I haven't got time to look at this right now before I leave on holiday
but I'll make one couple of general points.
Your implementation of model element property panels will replace the
existing version within the property tab.
So I'd be careful about basing your design to much on the history of
our existing code where we may have problems in our existing
implementation with cyclic dependencies and controls rebuilding too
frequently when they receive events. This is a chance to improve upon
the existing design.
I see your project as becoming a new subsystem, ModelElementProperties
subsystem, that will replace our existing property panels for model
elements so if there are controls used only by the current
implementation that are causing you trouble to reuse then I wouldn't
hesitate to rewrite them within your own module or copy to your own
module on modify for your purpose (as Tom mentioned in a previous mail
though do keep authors intact should you do that). The old controls
will then become deprecated when your new module goes live.
Another major difference with the current implementation is that
panels are currently cached. One instance exists for each model
element type so that every time a Class is selected it is in fact the
same Class prop panel that's returned. So the current prop panels have
to listen for changes to the target to rebuild their data when the
target is changed. I think some of the controls on these prop panels
may be listening for target change to rebuild themselves.
For the new panels we won't be doing any caching. Instead, when the
target changes we just allow the old panel contents to be garbage
collected and create a new panel. It might seem that we're throwing
away some efficiency but I suspect we're actually causing more
problems then we're solving with our current cache with controls as
well as the panel itself having to listen for target changes.
We also want the flexibility in future to be able to build a prop
panel from multiple selected targets. Say for example the user selects
2 model elements of different types. The factory building the panel
contents should be able to determine what controls are relevant for
both model elements by seeing what is common in the XML for each. At
the very least this will then become a way of allowing the user to
change namespace for multiple model elements. (consider this paragraph
out of scope for GSOC unless you finish early but bear in mind for
your design that we want this in future).
I'll be taking a snapshot of your work away with me to review while on
holiday and will get back to you early next week.
Cheers
Bob.
2008/6/23 Christian López Espínola <[EMAIL PROTECTED]>:
> Hi,
>
> I was creating my custom per element property panels when the
> setTarget of the panel is called, but it was giving some problems with
> the namespace's target setting, because when I create it, the target
> is not set and I cannot call setTarget (I'd have to increase its
> visibility, and don't know yet if this will do the trick).
>
> Michiel suggested that I should use an Element PropPanel factory, and
> I created one and registered it in the enable() method of the module:
>
> public boolean enable() {
> /* Set up the property panels for UML elements: */
> PropPanelFactory elementFactory = new XMLPropPanelFactory();
> PropPanelFactoryManager.addPropPanelFactory(elementFactory);
> return true;
> }
>
> But the createPropPanel(Object target) method at my
> XMLPropPanelFactory is never called.
>
> I'm doing anything wrong?
>
> --
> Cheers,
>
> Christian López Espínola <penyaskito>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
