Hi Marcelo, it's a great suggest.
To anyone interested by this toolkit feel free to join the official forum at : http://groups.google.com/group/puremvc4gwt Regards. Luciano On 25 sep, 00:12, "marcelo melo" <[EMAIL PROTECTED]> wrote: > Hi, > > I've been working on a project with PureMVC for Flex for some time and > I really like it. > > When looking at the example I've noticed a small difference from the > GWT implementation, that is the necessity of creating a Provider for > executing the Commands. > > While I understand that it must be done because GWT does not let one > use reflection, I think that a small change could remove the necessity > of such Provider. > If, at the Controller and MacroCommand classes, instead of receiving > references to Class<? extends ICommand> , the parameter becomes an > instance of ICommand, and when invoking the registerCommand or > subCommand we pass a new Instance of the desired Command, it could be > achieved. > > The only difference I see is that there would be always the same > reference to the Commands, instead of creating a new instance each > time. I don't know if that would be a problem. > > I have the modified code, and it runs fine with the login example, and > I could send it to you (Luciano). By the way, are you brazilian? > > Thanks > > On Sat, Sep 20, 2008 at 5:44 PM, Luciano Broussal > > <[EMAIL PROTECTED]> wrote: > > > Thomas, > > > Thanks for your interesting point of view. > > > Feel free to checkout the project and you can help me to get it > > better. > > > Currently is a port of the java version of PureMVC but i didn't want > > to change it to not loose people who already know and use PureMVC > > with other languages. > > > Regards. > > > On 20 sep, 21:31, Thomas Broyer <[EMAIL PROTECTED]> wrote: > >> Hi Luciano, > > >> On 19 sep, 19:27, Luciano Broussal <[EMAIL PROTECTED]> wrote: > > >> > Here is the > >> > documentationhttp://puremvc.org/component/option,com_wrapper/Itemid,174/. > >> > It is available on the PureMVC Home page. > > >> Thanks (so it was the thing called "best practices" ;-) ) > > >> > Maybe you don't like but i'm not sure you can do more simple than the > >> > 15 classes which compose PureMvc and help the developper to separate > >> > layers and the main design patterns it use : > > >> > Proxy > >> > Facade. > >> > Medialor > >> > Commands > >> > View > >> > Controller > > >> Don't get me wrong, I didn't say I dislike PureMVC or its approach, > >> quite the contrary actually! > >> Two things though: > >> - I'm not a fan of frameworks, I prefer libraries/toolkits and a set > >> of patterns > >> - given that the PureMVC framework preferred usage is through the > >> "patterns" (Façade, Proxy, Mediator, Command), why not making it > >> lighter with mostly those classes and a few helper classes? (e.g. > >> Model Controller and View are masked behind Facade, just get rid of > >> the singletons and > > >> > Anyway, thank you for had a look to the project. > > >> Some thoughts: > >> - PureMVC best practices, page 28, reads: "Because of its > >> readability, and the ease of which one may refactor to add or remove > >> Notifications handled, the 'switch / case' construct is preferred over > >> the 'if / else if' expression style inside the handleNotifications > >> method." Given that you cannot do switch/case on strings in Java, I'd > >> replace the Notification names with integer identifiers. An Enum could > >> be used but that would mean making the classes generics: Facade<E > >> extends Enum>, etc. (to be implemented as "ApplicationFacade extends > >> Facade<ApplicationConstants>"). > >> - AFAIK, a Flex application must inherit mx.core.Application, so it > >> can't inherit Facade at the same time; hence the dichotomy; but in GWT > >> we implement EntryPoint, so the Facade could be the EntryPoint, with > >> appropriate abstract methods to avoid the need for explicitly calling > >> a "startup" method. This might lead to "bad uses" of the framework > >> though, where the façade would have direct access to > >> - I haven't yet read the "best practices" 'til the end but couldn't a > >> Mediator be a Composite? > >> - I'm concerned that there's no notion of "relevant" mediators at a > >> given time (e.g. in a tabbed app, the components outside the active > >> tab are "irrelevant", so handling of notifications could just be "mark > >> as dirty" and when the components become "relevant" again, they can re- > >> build or update their UI subcomponents); or should it be handled on > >> the "visual component" side and have the mediator handle notifications > >> independently of this relevant/irrelevant state) > > >> The EntryPoint as Facade and Mediator as Composite would drastically > >> reduce the sample's code... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
