The Tapestry philosophy is also to give the developer a clear and solid way to organize its sources through naming conventions, maybe we should first try to design a way of structuring a project that hold portlets in it.
I am wondering if it would not be easier to have a complete pipeline processor dedicated to portlets from the Dispatcher to RequestHandler. The existing result processors should be adapted to add support of new return types. I don't think that the existing Tapestry objects will completely fit to the portlets needs, especially with portlet 2.0 specifications. So we have to provide more tools that suits to portlet development. 2011/9/15 Amaury Willemant <[email protected]> > Hi > > It could be a good idea to respect a part of the Tapestry's philosophy. > Indeed, when you develop a webapp with Tapestry, you don't have to worry > about how it works, it just works and seems magical ! You just have to > write > your templates, components, mixins and that's it. > > The Tapestry Portlet Contribution could be invisible. I see it like this : > you just add the Portlet Contribution Module to your classpath and the only > difference will be the fact that it won't be mandatory to encapsulate your > templates in a <html> tag anymore. > > We should also give an entry point in this contribution, for the developers > who want to extend the mechanisms and for example use the > PortletPreferences, the Portlets mode and status explicitly. > > Now I must admit that it is very difficult to see a direct mapping between > the RenderRequest/ActionRequest/ResourcesRequest/EventRequest of the > Portlet > JSR and the Action/Render mechanism of Tapestry. > In the same way, if we want to make interportlet communication, should we > merge the Tapestry Events with the PortletEvents ? should we encapsulate > the > PortletSession in the ApplicationState Manager ? > > I am also confused and realize the amount of work to finish this > contribution. That's why I go back to work immediately ;) > > Thank you in advance for your ideas ! > > > > 2011/9/14 Christophe Cordenier <[email protected]> > > > Hi > > > > I finally found some time to work on tapestry5 portlet 2.0 integration > and > > i > > am so happy to do tweak Tapestry again. > > > > By the way, I still feel uncomfortable with putting the whole Tapestry > PATH > > in a single request parameter per portlet instance, as the existing > > contribution does. I feel like i'm missing something with all the tooling > > around portlets. The inherent concepts of Tapestry and portlet are so > > close, > > and at the same time so different in the implementation. Tapestry has > only > > one Request Type when portlets provide a different type of request and > > response per type of request. > > > > Also portlet containers already implement some kind of "redirect after > > post" > > as tapestry does, so which one should i keep ? > > > > Here are just my confused thoughts :) > > > > Any hint ? > > > > -- > > Regards, > > Christophe Cordenier. > > > > Committer on Apache Tapestry 5 > > Co-creator of wooki @wookicentral.com > > > -- Regards, Christophe Cordenier. Committer on Apache Tapestry 5 Co-creator of wooki @wookicentral.com
