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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
