On Tue, May 15, 2012 at 6:51 AM, Bernd Müller <bernd.mueller_at_ostfalia.de>wrote:
>
>
> Am 14.05.2012 18:04, schrieb Martin Marinschek:
> > Hi all,
> >
> > I am reviewing as from Ed's presentation on con-fess:
> >
> > - I don't think it makes sense to put the flow definition into VDL -
> > this has to be seperate (as snippets in the same format you would put
> I agree and suggest ONE such artefact for the complete flow.
> It's easier to find inconsistencies and conflict at one
> place than to look into many different files
+1
>
> regards
>
> Bernd
> > in the faces-config)
> > - I do think an implicit flow makes sense (if you put all files into
> > this one folder, you will have implicitly created a flow already, as
> > long as you navigate within, you stay in the flow, when you navigate
> > out, you leave the flow or - and this will be interesting to decide
> > between these cases - you create a subflow) - however, you would need
> > to have hooks in the flow controller to take care of these cases
> > (getting into/leaving the flow)
> > - I don't understand why we need additional constructs like switches
> > etc. - for me a flow is just navigation as before. If you want to add
> > a switch, it should also be in the "normal" navigation, no?
> >
> > best regards,
> >
> > Martin
> >
> > On 5/14/12, Bernd Müller <bernd.mueller_at_ostfalia.de> wrote:
> >> investigate on the examples. Work fine for me at the moment.
> >> However, it's difficult to get the basic idea for me personally.
> >> I hope to find more time to work with.
> >> One point: all *-javadoc.jar of may are empty. one has to
> >> look into the source
> >>
> >> Bernd
> >>
> >> Am 02.05.2012 15:21, schrieb Edward Burns:
> >>>>>>>> On Tue, 27 Mar 2012 09:13:49 -0700, Edward Burns
> >>>>>>>> <edward.burns_at_oracle.com> said:
> >>>
> >>>>>>>> On Mon, 26 Mar 2012 20:03:10 -0600, David Schneider
> >>>>>>>> <david.schneider_at_oracle.com> said:
> >>> DS> Sorry for the late response, I've been a bit under the weather
> >>> lately.
> >>>
> >>> DS> On 3/16/2012 9:01 AM, Edward Burns wrote:
> >>> DS> This flow is used to create/edit some type of data record (e.g. a
> >>> DS> customer contact, employee, etc.). The flow's starting point, its
> >>> DS> 'default activity', is indicated with the green halo.
> >>>
> >>> EB> Obviously the router is an embodiment of some logic. How is the
> >>> logic
> >>> EB> encoded? A java method invocation? I don't have "Router Activity"
> >>> EB> correctly represented in the proposal [1]. David, can you please
> say
> >>> EB> what I should put for "Router Activity"?
> >>>
> >>> DS> In ADF a router activity is the control flow equivalent of a switch
> >>> DS> statement. It consists of a sequence of EL value expressions and
> an
> >>> DS> outcome value to be generated if the EL evaluates to 'true'.
> There's
> >>>
> >>> DS> also a default outcome to be generated if none of the expressions
> >>> DS> evaluate to 'true'. In theory the same thing can be done with a
> >>> single
> >>> DS> Java method call but we found in some cases developers preferred
> being
> >>>
> >>> DS> able to use metadata instead of code, especially if IDE support is
> >>> DS> available for generating the metadata.
> >>>
> >>> EB> Thanks, I've updated the proposal.
> >>>
> >>> In the 25 business days since this email, I've been hard at work on
> >>> building a protype of this feature and I have something that I hope
> will
> >>> stimulate EG discussion.
> >>>
> >>> Details about the prototype
> >>> ===========================
> >>>
> >>> A very early, yet functional, prototype of the feature exists in the
> >>> nightly builds of mojarra. To evaluate the prototype, take the
> >>> org.glassfish:javax.faces:2.2.0-SNAPSHOT jar from maven.java.net and
> >>> drop it into GlassFish 3.1.1 or later. The Mojarra trunk workspace has
> >>> three test projects that exercise the extent of the prototype. These
> >>> tests are located in the test/web-profile/flow directory of the Mojarra
> >>> workspace. Unfortunately, due to [1], the jar artifact produced from
> >>> the mojarra-cdi-extension project within that directory is necessary to
> >>> put into WEB-INF/lib to enable the feature to work. The three simple
> >>> tests can be examined in their increasing order of complexity
> >>>
> >>> basic
> >>> basic-multi-page
> >>> intermediate
> >>>
> >>> The intermediate one is only partly fleshed out and is based on a
> design
> >>> given to me by David Schneider.
> >>>
> >>> Details about the specification of the feature
> >>> ==============================================
> >>>
> >>> ACTION: Experts, please follow the review instructions in this
> paragraph
> >>> and followup to this email with your feedback. I need significant
> >>> discussion to happen on this thread and reach some kind of consensus by
> >>> 15 May.
> >>>
> >>> Please take a look at the latest published generated specification in
> >>> the -javadoc.jar for the javax.faces:javax.faces-api:2.2-SNAPSHOT [2]
> >>> Within there, view the class javadocs for javax.faces.flow.FlowHandler.
> >>> Start here when reviewing the specification of the feature. Once
> you've
> >>> reviewed that class, look at the other classes in the javax.faces.flow
> >>> package. Once you've done that, look at the VDLDoc for the new "Faces
> >>> Flows" tag library. This can be accessed by clicking on the "Facelets
> >>> Tag Documentation" link in the top navigator and selecting the "Faces
> >>> Flows" tag library. Of all the prototype work in the spec and
> >>> implementation, this part is the most raw, so please bear that in mind
> >>> when reviewing.
> >>>
> >>> This is the last revision of the spec I'm making before coming to
> Martin
> >>> Marinschek's CON_FESS conference next week [3]. Perhaps we'll have
> some
> >>> time to informally discuss the feature there, but I am not going to go
> >>> for a formal EG meeting during the CON_FESS this year.
> >>>
> >>> I sincerely hope this elicits some discussion.
> >>>
> >>> Ed
> >>>
> >>> [1] http://java.net/jira/browse/JAVASERVERFACES-2404
> >>>
> >>> [2] type javax.faces:javax.faces-api:2.2-SNAPSHOT in to the search box
> >>> at <maven.java.net>. Select the -javadoc.jar artifact in the tree
> >>> browser. Select the Archive Browser tab. Expand the tree browser
> >>> within the Archive Browser tab and click on index.html. Click on "JSF
> >>> API Documentation".
> >>>
> >>
> >>
> >
> >
>
>
>