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.
>
> 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]
