jsr344-experts@javaserverfaces-spec-public.java.net

[jsr344-experts] Re: [jsr344-experts mirror] Re: [730-TaskFlows] PROPOSAL

From: Werner Keil <werner.keil_at_gmail.com>
Date: Tue, 15 May 2012 15:05:34 +0200

+1
(unless there was a configuration and deployment benefit, e.g. by allowing
some of the files to be deployed *separately *for different *
environments/stages*)

On Tue, May 15, 2012 at 2:58 PM, Kito Mann <kito.mann_at_virtua.com> wrote:

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