You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Duong BaTien <du...@gmail.com> on 2005/05/27 15:53:35 UTC
{Shale] Dialog and Tiles
Re post from myfaces to appropriate list.
>>> http://wiki.apache.org/struts/StrutsShale
>>>
>>> The javadoc actually contains quite a bit of explanation. The
>>> usescases are also built nightly and they are an excellent
>>> example of
>>> how the new dialog stuff works.
>>>
>>
>> I posted a blog entry on Shale Web Flow the other day. See /http://
>> jroller.com/page/dgeary
>>
>>
>> david
>>
>>
Hello David:
I manage to get back to Shale Dialog and read your blog on Shale Web
Flow. Craig just comes back from vacation. Welcome back ;-). So i
decide to fire up some of the questions. Hope you two may save me time
to dig around.
1) You said Shale loads the state's view using the supplied viewId
(which i am able to replace my previous implementation under
DialogController to the new Dialog - it is great to see similar
structure like web flow: flow and sub-flow), and soon we will be able to
supply a tile based on your work. I wonder what is its implication?
2) If i recalled in the previous version of DialogController, Craig
said "soon" we will be able to have different instances of
DialogController, controlling different fragments (tiles) in the same
page, so the deprecated DialogController is similar to Tiles controller
but it can last more than a request. I look at the new Dialog Status and
StatusImpl, there is only 1 property "data". Hence, at any point you
can only associate 1 state to the {dialog.data}. I wonder how different
work flows can be independently associated to different fragments in the
same page? Specifically, i am thinking different work flows are
associated with different applications; each application occupies 1 or 2
fragments of a portal page.
3) I have a project with dead line in the next 5 months. Will the new
tiles be able to handle i18n for English and French as the original
version or i have to create a complete mirror sites?
Thanks.
BaTien
DBGROUPS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: {Shale] Dialog and Tiles
Posted by Duong BaTien <du...@gmail.com>.
On Fri, 2005-05-27 at 13:43 -0600, David Geary wrote:
> Le May 27, 2005 à 11:50 AM, Craig McClanahan a écrit :
>
> > On 5/27/05, Duong BaTien <du...@gmail.com> wrote:
> >
> >> Re post from myfaces to appropriate list.
> >>
> >>
> >>>>> http://wiki.apache.org/struts/StrutsShale
> >>>>>
> >>>>> The javadoc actually contains quite a bit of explanation. The
> >>>>> usescases are also built nightly and they are an excellent
> >>>>> example of
> >>>>> how the new dialog stuff works.
> >>>>>
> >>>>>
> >>>>
> >>>> I posted a blog entry on Shale Web Flow the other day. See /http://
> >>>> jroller.com/page/dgeary
> >>>>
> >>>>
> >>>> david
> >>>>
> >>>>
> >>>>
> >> Hello David:
> >>
> >> I manage to get back to Shale Dialog and read your blog on Shale Web
> >> Flow. Craig just comes back from vacation. Welcome back ;-). So i
> >> decide to fire up some of the questions. Hope you two may save me
> >> time
> >> to dig around.
> >>
> >> 1) You said Shale loads the state's view using the supplied viewId
> >> (which i am able to replace my previous implementation under
> >> DialogController to the new Dialog - it is great to see similar
> >> structure like web flow: flow and sub-flow), and soon we will be
> >> able to
> >> supply a tile based on your work. I wonder what is its implication?
> >>
> >
> > I'll let David speak to where Tiles is.
>
> If you use Tiles with Shale dialogs, your dialog views are most
> likely JSP pages that simply load a tile. After we get Tiles
> integrated with Shale, you'll be able to specify that tile directly.
>
>
> david
>
Followings are what i am doing and it currently works under myfaces
TilesViewHandler. I wonder what extra things i may get or issues i may
have when tiles is integrated with Shale.
1) the display fragment of a portal page is a jsp, specified for
Shale viewId.
2) myfaces translates that page request into a .tiles, which is
configured via a tiles definition; the content of the display fragment
is the viewId jsp.
Any extra suggestions and/or comments from any one are welcome.
Thanks
BaTien
DBGROUPS
> >
> >
> >>
> >> 2) If i recalled in the previous version of DialogController, Craig
> >> said "soon" we will be able to have different instances of
> >> DialogController, controlling different fragments (tiles) in the same
> >> page, so the deprecated DialogController is similar to Tiles
> >> controller
> >> but it can last more than a request. I look at the new Dialog
> >> Status and
> >> StatusImpl, there is only 1 property "data". Hence, at any point you
> >> can only associate 1 state to the {dialog.data}. I wonder how
> >> different
> >> work flows can be independently associated to different fragments
> >> in the
> >> same page? Specifically, i am thinking different work flows are
> >> associated with different applications; each application occupies
> >> 1 or 2
> >> fragments of a portal page.
> >>
> >
> > That use case is going to require some additional machinery that uses
> > different dialog instances (i.e. different session scope Status
> > instances) for the various simultaneously executing dialogs. It will
> > also require the framework to maintain an association with each
> > fragment and the corresponding status instance for the owning dialog.
> > Hmm ... between the dynamic subview stuff/Tiles/Clay we can probably
> > deal with the components side of that fairly gracefully; the
> > interesting bit will be the server side state. Gotta think a bit more
> > on that one.
> >
> >
> >>
> >> 3) I have a project with dead line in the next 5 months. Will the new
> >> tiles be able to handle i18n for English and French as the original
> >> version or i have to create a complete mirror sites?
> >>
> >>
> >
> > Do you need more than the support that JSF already provides for i18n?
> > Things like:
> >
> > <f:loadBundle var="messages"
> > basename="com.mycompany.mypackage.Bundle"/>
> > ...
> > <h:outputText value="#{messages['prompt.username']}"/>
> > ...
> > <h:commandButton ... value="#{messages['label.save']}"/>
> >
> >
> >
> >> Thanks.
> >>
> >> BaTien
> >> DBGROUPS
> >>
> >>
> >
> > Craig
> >
> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: {Shale] Dialog and Tiles
Posted by David Geary <sa...@earthlink.net>.
Le May 27, 2005 à 11:50 AM, Craig McClanahan a écrit :
> On 5/27/05, Duong BaTien <du...@gmail.com> wrote:
>
>> Re post from myfaces to appropriate list.
>>
>>
>>>>> http://wiki.apache.org/struts/StrutsShale
>>>>>
>>>>> The javadoc actually contains quite a bit of explanation. The
>>>>> usescases are also built nightly and they are an excellent
>>>>> example of
>>>>> how the new dialog stuff works.
>>>>>
>>>>>
>>>>
>>>> I posted a blog entry on Shale Web Flow the other day. See /http://
>>>> jroller.com/page/dgeary
>>>>
>>>>
>>>> david
>>>>
>>>>
>>>>
>> Hello David:
>>
>> I manage to get back to Shale Dialog and read your blog on Shale Web
>> Flow. Craig just comes back from vacation. Welcome back ;-). So i
>> decide to fire up some of the questions. Hope you two may save me
>> time
>> to dig around.
>>
>> 1) You said Shale loads the state's view using the supplied viewId
>> (which i am able to replace my previous implementation under
>> DialogController to the new Dialog - it is great to see similar
>> structure like web flow: flow and sub-flow), and soon we will be
>> able to
>> supply a tile based on your work. I wonder what is its implication?
>>
>
> I'll let David speak to where Tiles is.
If you use Tiles with Shale dialogs, your dialog views are most
likely JSP pages that simply load a tile. After we get Tiles
integrated with Shale, you'll be able to specify that tile directly.
david
>
>
>>
>> 2) If i recalled in the previous version of DialogController, Craig
>> said "soon" we will be able to have different instances of
>> DialogController, controlling different fragments (tiles) in the same
>> page, so the deprecated DialogController is similar to Tiles
>> controller
>> but it can last more than a request. I look at the new Dialog
>> Status and
>> StatusImpl, there is only 1 property "data". Hence, at any point you
>> can only associate 1 state to the {dialog.data}. I wonder how
>> different
>> work flows can be independently associated to different fragments
>> in the
>> same page? Specifically, i am thinking different work flows are
>> associated with different applications; each application occupies
>> 1 or 2
>> fragments of a portal page.
>>
>
> That use case is going to require some additional machinery that uses
> different dialog instances (i.e. different session scope Status
> instances) for the various simultaneously executing dialogs. It will
> also require the framework to maintain an association with each
> fragment and the corresponding status instance for the owning dialog.
> Hmm ... between the dynamic subview stuff/Tiles/Clay we can probably
> deal with the components side of that fairly gracefully; the
> interesting bit will be the server side state. Gotta think a bit more
> on that one.
>
>
>>
>> 3) I have a project with dead line in the next 5 months. Will the new
>> tiles be able to handle i18n for English and French as the original
>> version or i have to create a complete mirror sites?
>>
>>
>
> Do you need more than the support that JSF already provides for i18n?
> Things like:
>
> <f:loadBundle var="messages"
> basename="com.mycompany.mypackage.Bundle"/>
> ...
> <h:outputText value="#{messages['prompt.username']}"/>
> ...
> <h:commandButton ... value="#{messages['label.save']}"/>
>
>
>
>> Thanks.
>>
>> BaTien
>> DBGROUPS
>>
>>
>
> Craig
>
>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: {Shale] Dialog and Tiles
Posted by Craig McClanahan <cr...@gmail.com>.
On 5/27/05, Duong BaTien <du...@gmail.com> wrote:
> Re post from myfaces to appropriate list.
>
> >>> http://wiki.apache.org/struts/StrutsShale
> >>>
> >>> The javadoc actually contains quite a bit of explanation. The
> >>> usescases are also built nightly and they are an excellent
> >>> example of
> >>> how the new dialog stuff works.
> >>>
> >>
> >> I posted a blog entry on Shale Web Flow the other day. See /http://
> >> jroller.com/page/dgeary
> >>
> >>
> >> david
> >>
> >>
> Hello David:
>
> I manage to get back to Shale Dialog and read your blog on Shale Web
> Flow. Craig just comes back from vacation. Welcome back ;-). So i
> decide to fire up some of the questions. Hope you two may save me time
> to dig around.
>
> 1) You said Shale loads the state's view using the supplied viewId
> (which i am able to replace my previous implementation under
> DialogController to the new Dialog - it is great to see similar
> structure like web flow: flow and sub-flow), and soon we will be able to
> supply a tile based on your work. I wonder what is its implication?
I'll let David speak to where Tiles is.
>
> 2) If i recalled in the previous version of DialogController, Craig
> said "soon" we will be able to have different instances of
> DialogController, controlling different fragments (tiles) in the same
> page, so the deprecated DialogController is similar to Tiles controller
> but it can last more than a request. I look at the new Dialog Status and
> StatusImpl, there is only 1 property "data". Hence, at any point you
> can only associate 1 state to the {dialog.data}. I wonder how different
> work flows can be independently associated to different fragments in the
> same page? Specifically, i am thinking different work flows are
> associated with different applications; each application occupies 1 or 2
> fragments of a portal page.
That use case is going to require some additional machinery that uses
different dialog instances (i.e. different session scope Status
instances) for the various simultaneously executing dialogs. It will
also require the framework to maintain an association with each
fragment and the corresponding status instance for the owning dialog.
Hmm ... between the dynamic subview stuff/Tiles/Clay we can probably
deal with the components side of that fairly gracefully; the
interesting bit will be the server side state. Gotta think a bit more
on that one.
>
> 3) I have a project with dead line in the next 5 months. Will the new
> tiles be able to handle i18n for English and French as the original
> version or i have to create a complete mirror sites?
>
Do you need more than the support that JSF already provides for i18n?
Things like:
<f:loadBundle var="messages" basename="com.mycompany.mypackage.Bundle"/>
...
<h:outputText value="#{messages['prompt.username']}"/>
...
<h:commandButton ... value="#{messages['label.save']}"/>
> Thanks.
>
> BaTien
> DBGROUPS
>
Craig
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org