Hi All ! For T5.4 and portlet integration, I would like to add a parameter for link creation API, as we have the forForm boolean parameter, a "forAjax" would be really helpful to identify the type of PortletURL to generate. (in our case it's a portlet ResourceURL)
After a deeper analysis of impact, i think that the rest of Tapestry portlet API integration can be done outside of the core through decorators and aliases. By the way, i have succeeded to handle exception report by using a flash property in the session to store the latest exception. It can be improved but works. Christophe. 2011/9/15 Christophe Cordenier <[email protected]> > 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 > -- Regards, Christophe Cordenier. Committer on Apache Tapestry 5 Co-creator of wooki @wookicentral.com
