You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Christophe Cordenier <ch...@gmail.com> on 2011/09/14 18:07:11 UTC
Tapestry5 Portlet Contribution
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
Re: Tapestry5 Portlet Contribution
Posted by Christophe Cordenier <ch...@gmail.com>.
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 <ch...@gmail.com>
> 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 <aw...@gmail.com>
>
>> 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 <ch...@gmail.com>
>>
>> > 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
Re: Tapestry5 Portlet Contribution
Posted by Christophe Cordenier <ch...@gmail.com>.
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 <aw...@gmail.com>
> 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 <ch...@gmail.com>
>
> > 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
Re: Tapestry5 Portlet Contribution
Posted by Amaury Willemant <aw...@gmail.com>.
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 <ch...@gmail.com>
> 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
>