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