On Aug 21, 6:56 am, Dave <[email protected]> wrote: > I would like to extend this by allowing developers to produce custom > forms. i.e allow developers to add in there own CustomTreeItems, > without having to recompile with my code. > My inital plan was to have a directory in the classpath, so at runtime > a class loader on the server side would look for any classes that were > derived from my CustomTreeItem in that folder and load them. > The client would make an RPC request for the tree items, so it could > build up the Tree. I quickly discovered that VerticalPanel couldn't > be serialized (I assume because this is translated to javascript), so > this wouldn't work.
Hi, I didn't write much code yet in GWT (been watching projects for quite some times now, but never got into serious programming with it... until now), but your approach doesn't seem write from the base. :) Sorry to pull this off so soon, but there is a lack of reusable pattern here. Patterns are proven and tested in software engineering. OO programming is nice because you can relate to real world example to explain stuff; in a big corporation, the more responsibilities employees have, the harder it is to manage them, and the whole society. (Think about replacing 1 employee to knows many things in the corporation vs. replacing an employee who know only one thing, for example.) Well, programming is pretty much the same, the more parts of you application knows about other parts, the harder it is to add/ remove parts of it. For example, take a look at the MVP pattern, you'll see that your tree doesn't even have to know your vertical panel at all. This way, you can provide anything to handle your tree item selection. One option would have to have the tree items have a method like node.getType() that would return some enum value. Upon item click, an event would be fired across the event bus based on the node type, which would then notify the associated command, which would then execute the proper code to display whatever needs to be displayed with the selected node. Then adding new functionality to your application (or removing some) would simply be a matter of registering new node types (model), associate them with new events (provider), and display whatever needs to be displayed by the associated action command in an associated widget (view). The level of complexity is up to you. But don't just take my word for it, Google IO 2009 have some nice educational videos that you can watch to be convinced :) Hope this helps. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
