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

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

From: Martin Marinschek <mmarinschek_at_apache.org>
Date: Mon, 14 May 2012 18:04:19 +0200

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


-- 
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces