springframework-developer — Spring Framework developers list

[Springframework-developer] webflow: FormAction question

[Steven D. <ste...@gm...>]

Hi,

I want to create a wizard that spans across multiple pages. I want to
bind to one and the same form instance across the different pages and
validate on every page submit. When the wizard completes I want this
one instance to contain all the information entered through the
various forms.

Can I use FormAction for this purpose?

Thanks

Steven

-- 
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

[Erwin V. <erw...@er...>]

As I mentioned in previous posts, we've now got a pluggable 
FlowExecutionStorage strategies so we basically have all options open now. I 
set it up in such a way that we don't even need any special handling in the 
view (via a custom tag or so): the storage strategy is completely pluggable: 
you could switch from service side to client side storage without even 
affecting your views (JSPs), just by doing a bit of config in your 
application context!

Erwin Vervaet
erw...@er...
----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: <spr...@li...>
Sent: Friday, April 01, 2005 10:12 PM
Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions - 
Feedback needed


> Tapestry 3.1/4.0 (the current CVS version of Tapestry) also makes this 
> pluggable... Storing page state in the Session is just the default.
>
> Alef Arendsen wrote:
>
>> It's what ASP.NET (and I think some JSF implementations) does as well - 
>> serialization of the state in a hidden input field. I don't think it'd be 
>> that difficult to implement a custom tag that does this, wouldn't it?
>>
>> rgds,
>> Alef
>>
>> On Mar 31, 2005, at 10:30 PM, Rob Harrop wrote:
>>
>>> I see no problem in implictly creating a session - although I am 
>>> concerned about the impact of this on clustered applications. Can the 
>>> session implementation be factored out so that users can implement their 
>>> own session storage?
>>>
>>> Rob
>>>
>>> Erwin Vervaet wrote:
>>>
>>>> The Spring Web Flow (SWF) FlowController forces the "requireSession" 
>>>> property it inherits from AbstractController to "true". This is logical 
>>>> since the webflow system needs to store flow execution state in the 
>>>> HTTP session.
>>>>
>>>> So far so good. However, since the controller now requires an existing 
>>>> session, the user/developer is responsible for creating that session 
>>>> before a flow is started. This is typically not a problem in real-life 
>>>> applications since those carefully manage session creation and 
>>>> invalidation.
>>>>
>>>> Still, we are wondering whether it is a good idea to implicitly create 
>>>> sessions (usually using request.getSession()) in a controller, or 
>>>> should this be left as a responsability of the application developer? 
>>>> Note that AbstractWizardFormController and AbstractFormController 
>>>> implicitly create sessions.
>>>>
>>>> Erwin Vervaet
>>>> erw...@er...
>>>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
> 

Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

[Erwin V. <erw...@er...>]

> What about an implementation that would 'do what is best'.  Save to
> the session if it already exists, serialize to the request if not. 
> Then have a custom tag to spit out the flow info in the form.  The tag
> would pull the serialized flow info from the request (if it exists)
> and add a new hidden input field for it (_flowInstance or
> something)...otherwise if a session exists and the info is on the
> session it would spit out what is expected now (the _* hidden fields).
> At the beginning of a request, it would look to see if the serialized
> param (_flowInstance) is on the request first...if so, deserialize. 
> If not, see if a session exists and pull from the session using _*
> params.

Interesting idea to have it automatically select request or session based
storage. I added pluggable FlowExecutionStorage strategies this morning
so this would be trivial to do.

Also, I implemented a "client side flow execution" storage strategy and it
is just encoding the entire flow execution in the flowExecutionId. No need
for any special handling in the views, the storage strategy is completely
pluggable!

> If you have a truly complex object graph, set a 'requiresSession'
> boolean to true (defaults to false)...although I would think it best
> to try and keep it as simple as possible when going in the session.
> 
> With this approach your not doing more than you need (when a session
> does exist), and (as a bonus) you can have flows that are used by
> non-session visitors and with-session users, and the impl would 'do
> what is best' in both situations.

Yep, nice!

I'm sure Keith is gonna blog about it, but
<gavingKingMode>
our new pluggable flow execution storage strategies kick some serious butt!
</gavingKingMode>

:)

Re: [Springframework-developer] SWF - Testing FlowBuilders

[Colin S. <col...@ex...>]

AbstractFlowExecutionTests is actually very useful. While a test 
deriving from it doesn't really test the builder directly (in 
isolation), it certainly does allow you to write a test (with as little 
effort as possible) to verify that your output flow from that builder 
behaves as expected, which I think is the important thing.

Erwin Vervaet wrote:

> This is one of the areas we're going to try and improve in the 
> upcoming preview2 release 
> (http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Change+Log). 
>
>
> You can already take a look at the class AbstractFlowExecutionTests, 
> but I haven't used that one myself yet so I can't really comment on 
> best practices or anything like that.
>
> Erwin Vervaet
> ----- Original Message ----- From: "Will Butler" 
> <wil...@ra...>
> To: <spr...@li...>
> Sent: Friday, April 01, 2005 10:55 PM
> Subject: [Springframework-developer] SWF - Testing FlowBuilders
>
>
>> Unit testing flow builders seems like a good idea, but it appears to be
>> a little difficult to do. We really want to be able to verify that the
>> states, transitions, actions, and views in the generated flow are what
>> we expect. Does anyone have any examples of how we can do this
>> effectively?
>>
>> Thanks!
>>
>> Will
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

[Erwin V. <erw...@er...>]

The storage interface doesn't need to worry about scoping: it only needs to 
deal with flow scope. Request scope and event scope never outlive the 
current request.

Erwin Vervaet
----- Original Message ----- 
From: "Rob Harrop" <ro...@ca...>
To: <spr...@li...>
Sent: Friday, April 01, 2005 11:00 AM
Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions - 
Feedback needed


> What about scoping - how will this be handled by the storage interface?
>
> Rob
>
> Keith Donald wrote:
>
>>Yes, so a HttpSessionFlowExecutionStorage would use the HttpSession, a
>>HttpRequestFlowExecutionStorage would use the request, for example.  The
>>latter would also have to know how to reconstruct the FlowExecution soley
>>from the request parameters, while the former would just pull an existing
>>instance from the HttpSession given the flowExecutionId in the input 
>>Event.
>>
>>Keith
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...] On Behalf 
>>Of
>>Seth Ladd
>>Sent: Thursday, March 31, 2005 7:56 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
>>Feedback needed
>>
>>On Thu, 31 Mar 2005 19:46:42 -0500, Keith Donald <ke...@in...>
>>wrote:
>>
>>>Seth,
>>>
>>>Excellent idea.
>>>
>>>If we extract an interface from the HttpServletExecutionManager, we get
>>>something like:
>>>
>>>public interface FlowExecutionStorage {
>>>    public FlowExecution loadFrom(Event inputEvent);
>>>    public void saveOrUpdate(FlowExecution flowExecution);
>>>    public void remove(FlowExecution flowExecution);
>>>}
>>>
>>>Or something like that.  Erwin what do you think? Need to think about it
>>>more.  I imagine here the FlowExecutionStack would have to be
>>>
>>reconstructed
>>
>>>from the Event parameters, for example: http request parameters, in an
>>>
>>http
>>
>>>servlet environment.  It also has to be rehydrated with services on
>>>deserialization as well, including the FlowLocator and its
>>>FlowExecutionListenerList.
>>>
>>
>>
>>Keith,
>>
>>Just so I'm clear... this isn't to replace the concept and purpose of
>>the HttpSession?  This is just to provide a way to get the state info
>>of the flow into the request to avoid the need for session creation?
>>
>>Thanks!
>>Seth
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by Demarc:
>>A global provider of Threat Management Solutions.
>>Download our HomeAdmin security software for free today!
>>http://www.demarc.com/info/Sentarus/hamr30
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by Demarc:
>>A global provider of Threat Management Solutions.
>>Download our HomeAdmin security software for free today!
>>http://www.demarc.com/info/Sentarus/hamr30
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 

Re: [Springframework-developer] SWF - Testing FlowBuilders

[Erwin V. <erw...@er...>]

This is one of the areas we're going to try and improve in the upcoming 
preview2 release 
(http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Change+Log).

You can already take a look at the class AbstractFlowExecutionTests, but I 
haven't used that one myself yet so I can't really comment on best practices 
or anything like that.

Erwin Vervaet
----- Original Message ----- 
From: "Will Butler" <wil...@ra...>
To: <spr...@li...>
Sent: Friday, April 01, 2005 10:55 PM
Subject: [Springframework-developer] SWF - Testing FlowBuilders


> Unit testing flow builders seems like a good idea, but it appears to be
> a little difficult to do. We really want to be able to verify that the
> states, transitions, actions, and views in the generated flow are what
> we expect. Does anyone have any examples of how we can do this
> effectively?
>
> Thanks!
>
> Will
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
> 

Re: [Springframework-developer] Changes to build.xml to run autobuilds build on 1.5 as well

[Colin S. <col...@ex...>]

I am. It seems fairly random too, i.e. last night I sent an email to the 
user list and cc'ed the dev list, and it showed up on one list 
immediately, but only this morning on the other.

Alef Arendsen wrote:

> Anybody else having experiencing major delays with the mailinglist???
>
> ------------------------------------------------------------------------
> *From:* spr...@li... 
> [mailto:spr...@li...] *On 
> Behalf Of *Alef Arendsen
> *Sent:* Thursday, March 31, 2005 5:46 PM
> *To:* spr...@li...; 
> spr...@li...
> *Subject:* RE: [Springframework-developer] Changes to build.xml to run 
> autobuilds build on 1.5 as well
>
> You're right, but I'll be adding support for running the unit tests on 
> 1.4 as well... I was first thinking about adding a simple master build 
> script that executes the two builds (1.4 and 1.5) but the problem here 
> is that the 'ant' task does not support forking of a new JVM and doing 
> an 'exec' is not an option, since I want to preserve the log files. 
> JUnit does support the fork (we're already doing it) and you can also 
> specify a JVM to use.
>
> About building (compiling), I thought the behavior when building on 
> 1.5 in combination with adding the compatibility flag would be the 
> same as with building on 1.4, wouldn't it?
>
> Alef
>
>
> -----Original Message-----
> From: spr...@li... on behalf 
> of Juergen Hoeller
> Sent: Wed 3/30/2005 8:15 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Changes to build.xml to run 
> autobuilds build on 1.5 as well
>
> Well, I don't object to such a property in general. But such a 
> property only
> makes sense if you intend to build the 1.4 version on JDK 1.5: I don't 
> think
> there's much point in that; building the 1.5 version only would be
> sufficient then.
>
> The capability of our build script to build on 1.4 is really just 
> meant as a
> fallback for users that want to do custom builds on their 1.4 JDK. The 
> only
> value we could add to the auto-builds is to check that building the 1.4
> version actually works *on JDK 1.4*, which we can't check by building 
> on JDK
> 1.5...
>
> Juergen
>
>
>   -----Original Message-----
>   From: spr...@li...
> [mailto:spr...@li...]On Behalf Of
> Alef Arendsen
>   Sent: Wednesday, March 30, 2005 4:32 PM
>   To: spr...@li...
>   Subject: [Springframework-developer] Changes to build.xml to run
> autobuilds build on 1.5 as well
>
>
>   If nobody objects, I'll be modifying the build file to include an extra
> property that indicates whether or not you want to build on 1.5. I want to
> have the autobuild build for both 1.5 and 1.4 but I can't get this to work
> while maintaining the build numbers. To in addition to detecting the Java
> version automatically, there will be a property you can specify when 
> issuing
> an Ant command.
>
>   regards,
>   Alef
>

Re: [Springframework-developer] UpdatableSqlQuery (current wrong class name) vs. UpdateableSqlQuery (corrent name)

[Juergen H. <ju...@in...>]

Yes, let's rename the class and keep the old version as deprecated subclass
of it (i.e. UpdatableSqlQuery extends UpdateableSqlQuery).

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Friday, April 01, 2005 10:22 PM
To: spr...@li...
Subject: [Springframework-developer] UpdatableSqlQuery (current wrong
class name) vs. UpdateableSqlQuery (corrent name)


I just realized UpdatableSqlQuery is not actually correct, it should
really be UpdateableSqlQuery.

What do people think about creating a new correct version, and
deprecating the old class name?

Colin

--
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] FW: FlowExecutionStorage

[Keith D. <ke...@in...>]

fyi

Feel free to pitch in on the code review :-)

-----Original Message-----
From: Erwin Vervaet [mailto:erw...@er...] 
Sent: Saturday, April 02, 2005 5:51 AM
To: Keith Donald
Subject: FlowExecutionStorage
Importance: High

Hell yeah!

I was in the zone this morning!!
All code is in (and pretty much ready for release):

* reusable flow execution manager
* flow execution storage strategies
* server side (HttpSession) continuations
* client side continuations (requires Jakarta commons codec for Base64 
encoding)
* tranditional HttpSession flow execution storage
* storage strategy is completely transparent for the views

And all with very little code!

I tested all of it with the new sample app, which is still not in CVS (maybe

tonight). E.g. here a piece of config from that sample:

<bean id="frontController" name="/flow.htm" 
class="org.springframework.web.flow.mvc.FlowController">
   <property name="flowExecutionManager"><ref 
bean="flowExecutionManager"/></property>
</bean>

<bean id="flowExecutionManager" 
class="org.springframework.web.flow.execution.HttpServletRequestFlowExecutio
nManager">
   <property name="flowLocator">
      <bean 
class="org.springframework.web.flow.config.BeanFactoryFlowServiceLocator"/>
   </property>
   <!-- property name="flowExecutionStorage">
      <bean 
class="org.springframework.web.flow.execution.HttpSessionContinuationsFlowEx
ecutionStorage"/>
   </property -->
   <property name="flowExecutionStorage">
      <bean 
class="org.springframework.web.flow.execution.ClientSideContinuationsFlowExe
cutionStorage"/>
   </property>
</bean>

Just 2 minor things I encountered:

1) I had to make the logger static on FlowExecution because of issues with 
serialisation...
2) We still can't expose the flow execution and current state to a view 
rendered from a end-state because flowExecution.getCurrentStateId() throws 
an exception when the flow is no longer active....

Give all of it a good code review and see you tonight!

Erwin Vervaet
erw...@er... 

Re: [Springframework-developer] Integrating a singleton context loader w/ Acegi web filters?

[Colin S. <col...@ex...>]

Tim Kettering wrote:

> Hi everyone,
>
> I’m writing this in the hopes I can get some insight on how to 
> approach this. In the application we are developing, we have 
> determined that it is necessary to start up the spring context using a 
> singleton, to make it available to services that sit outside the web 
> application. So we are using the singleton class/approach that is 
> recommended by the Spring developers for this purpose.
>
> The issue I am facing now is that we are also making use of Acegi 
> Security, which relies on the use of a context loader listener (which 
> accepts a array of strings as parameters), to start up the filter 
> chain proxy in web.xml.
>
> Since for purposes of keeping duplication to a minimum, we’d obviously 
> want that the filter chain proxy access the context provided by the 
> singleton, instead of the context listener. So I’m wondering about the 
> best approach for this. I’m thinking either by modifying the 
> ContextLoaderListener to use the singleton instead, or modifying 
> things on the Acegi side.
>
> But I thought before I got too into hacking stuff, I would ask the 
> list in case there are any glaringly obvious (and simple) solutions to 
> this issue I am looking at that would save me the need to hack a 
> solution.
>
Tim,

(First of all, please make any replies to the user list, this email is 
better suited for that).

Unless I'm missing something, this is actually trivial to handle. The 
ContextLoader, since Spring 1.1.5 or 1.1.4, has been automatically able 
to load a parent context for the main web-app context, using the 
ContextSingletonBeanFactoryLocator to load that parent context. You're 
not outright saying that you're using 
ContextSingletonBeanFactoryLocator, but that's what you're implying.

Take a look at this web.xml file for an example of how to configure this:
http://cvs.sourceforge.net/viewcvs.py/springframework/spring/autobuilds/apps/integration/src/webapp/WEB-INF/web.xml?rev=1.2&view=markup

Regards,

-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

[Springframework-developer] spring Build Failed

[<al...@jt...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050402001529

[Springframework-developer] Integrating a singleton context loader w/ Acegi web filters?

[Tim K. <tim...@vi...>]

Hi everyone,

 

I'm writing this in the hopes I can get some insight on how to approach
this.  In the application we are developing, we have determined that it is
necessary to start up the spring context using a singleton, to make it
available to services that sit outside the web application.  So we are using
the singleton class/approach that is recommended by the Spring developers
for this purpose.  

 

The issue I am facing now is that we are also making use of Acegi Security,
which relies on the use of a context loader listener (which accepts a array
of strings as parameters), to start up the filter chain proxy in web.xml.  

 

Since for purposes of keeping duplication to a minimum, we'd obviously want
that the filter chain proxy access the context provided by the singleton,
instead of the context listener.  So I'm wondering about the best approach
for this.  I'm thinking either by modifying the ContextLoaderListener to use
the singleton instead, or modifying things on the Acegi side.  

 

But I thought before I got too into hacking stuff, I would ask the list in
case there are any glaringly obvious (and simple) solutions to this issue I
am looking at that would save me the need to hack a solution. 

 

Thanks!

 

-tim

[Springframework-developer] spring Build Failed

[<al...@jt...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050402000230

[Springframework-developer] SWF - Testing FlowBuilders

[Will B. <wil...@ra...>]

Unit testing flow builders seems like a good idea, but it appears to be
a little difficult to do. We really want to be able to verify that the
states, transitions, actions, and views in the generated flow are what
we expect. Does anyone have any examples of how we can do this
effectively?

Thanks!

Will

[Springframework-developer] UpdatableSqlQuery (current wrong class name) vs. UpdateableSqlQuery (corrent name)

[Colin S. <col...@ex...>]

I just realized UpdatableSqlQuery is not actually correct, it should 
really be UpdateableSqlQuery.

What do people think about creating a new correct version, and 
deprecating the old class name?

Colin

-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

[Colin S. <col...@ex...>]

Tapestry 3.1/4.0 (the current CVS version of Tapestry) also makes this 
pluggable... Storing page state in the Session is just the default.

Alef Arendsen wrote:

> It's what ASP.NET (and I think some JSF implementations) does as well 
> - serialization of the state in a hidden input field. I don't think 
> it'd be that difficult to implement a custom tag that does this, 
> wouldn't it?
>
> rgds,
> Alef
>
> On Mar 31, 2005, at 10:30 PM, Rob Harrop wrote:
>
>> I see no problem in implictly creating a session - although I am 
>> concerned about the impact of this on clustered applications. Can the 
>> session implementation be factored out so that users can implement 
>> their own session storage?
>>
>> Rob
>>
>> Erwin Vervaet wrote:
>>
>>> The Spring Web Flow (SWF) FlowController forces the "requireSession" 
>>> property it inherits from AbstractController to "true". This is 
>>> logical since the webflow system needs to store flow execution state 
>>> in the HTTP session.
>>>
>>> So far so good. However, since the controller now requires an 
>>> existing session, the user/developer is responsible for creating 
>>> that session before a flow is started. This is typically not a 
>>> problem in real-life applications since those carefully manage 
>>> session creation and invalidation.
>>>
>>> Still, we are wondering whether it is a good idea to implicitly 
>>> create sessions (usually using request.getSession()) in a 
>>> controller, or should this be left as a responsability of the 
>>> application developer? Note that AbstractWizardFormController and 
>>> AbstractFormController implicitly create sessions.
>>>
>>> Erwin Vervaet
>>> erw...@er...
>>

Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

[James E. <jam...@gm...>]

Not sure why this didn't come through...size?  I see it and another
post from Rob in the archive...just never got them (checked another
developer too).  If this is a duplicate for some, I apologize.

-----
What about an implementation that would 'do what is best'.  Save to
the session if it already exists, serialize to the request if not.
Then have a custom tag to spit out the flow info in the form.  The tag
would pull the serialized flow info from the request (if it exists)
and add a new hidden input field for it (_flowInstance or
something)...otherwise if a session exists and the info is on the
session it would spit out what is expected now (the _* hidden fields).
At the beginning of a request, it would look to see if the serialized
param (_flowInstance) is on the request first...if so, deserialize.
If not, see if a session exists and pull from the session using _*
params.

If you have a truly complex object graph, set a 'requiresSession'
boolean to true (defaults to false)...although I would think it best
to try and keep it as simple as possible when going in the session.

With this approach your not doing more than you need (when a session
does exist), and (as a bonus) you can have flows that are used by
non-session visitors and with-session users, and the impl would 'do
what is best' in both situations.

James

RE: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

[Keith D. <ke...@in...>]

What do you mean exactly?  If you mean getting/putting data in different
scopes, that's handled by another object: the RequestContext.  There is a
request Scope (requestContext.getRequestScope()) and a flow Scope
(requestContext.getFlowScope()).  Ultimately, hidden from the user of
course, Flow scope data gets managed in the active FlowSession object, which
is at the top of the FlowExecutionStack, which is serializable.

Is this what you wanted to hear? :-)

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Rob Harrop
Sent: Friday, April 01, 2005 4:01 AM
To: spr...@li...
Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
Feedback needed

What about scoping - how will this be handled by the storage interface?

Rob

Keith Donald wrote:

>Yes, so a HttpSessionFlowExecutionStorage would use the HttpSession, a
>HttpRequestFlowExecutionStorage would use the request, for example.  The
>latter would also have to know how to reconstruct the FlowExecution soley
>from the request parameters, while the former would just pull an existing
>instance from the HttpSession given the flowExecutionId in the input Event.
>
>Keith
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Seth Ladd
>Sent: Thursday, March 31, 2005 7:56 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
>Feedback needed
>
>On Thu, 31 Mar 2005 19:46:42 -0500, Keith Donald <ke...@in...>
>wrote:
>  
>
>>Seth,
>>
>>Excellent idea.
>>
>>If we extract an interface from the HttpServletExecutionManager, we get
>>something like:
>>
>>public interface FlowExecutionStorage {
>>    public FlowExecution loadFrom(Event inputEvent);
>>    public void saveOrUpdate(FlowExecution flowExecution);
>>    public void remove(FlowExecution flowExecution);
>>}
>>
>>Or something like that.  Erwin what do you think? Need to think about it
>>more.  I imagine here the FlowExecutionStack would have to be
>>    
>>
>reconstructed
>  
>
>>from the Event parameters, for example: http request parameters, in an
>>    
>>
>http
>  
>
>>servlet environment.  It also has to be rehydrated with services on
>>deserialization as well, including the FlowLocator and its
>>FlowExecutionListenerList.
>>    
>>
>
>
>Keith,
>
>Just so I'm clear... this isn't to replace the concept and purpose of
>the HttpSession?  This is just to provide a way to get the state info
>of the flow into the request to avoid the need for session creation?
>
>Thanks!
>Seth
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by Demarc:
>A global provider of Threat Management Solutions.
>Download our HomeAdmin security software for free today!
>http://www.demarc.com/info/Sentarus/hamr30
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by Demarc:
>A global provider of Threat Management Solutions.
>Download our HomeAdmin security software for free today!
>http://www.demarc.com/info/Sentarus/hamr30
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>


-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

[James E. <jam...@gm...>]

What about an implementation that would 'do what is best'.  Save to
the session if it already exists, serialize to the request if not. 
Then have a custom tag to spit out the flow info in the form.  The tag
would pull the serialized flow info from the request (if it exists)
and add a new hidden input field for it (_flowInstance or
something)...otherwise if a session exists and the info is on the
session it would spit out what is expected now (the _* hidden fields).
 At the beginning of a request, it would look to see if the serialized
param (_flowInstance) is on the request first...if so, deserialize. 
If not, see if a session exists and pull from the session using _*
params.

If you have a truly complex object graph, set a 'requiresSession'
boolean to true (defaults to false)...although I would think it best
to try and keep it as simple as possible when going in the session.

With this approach your not doing more than you need (when a session
does exist), and (as a bonus) you can have flows that are used by
non-session visitors and with-session users, and the impl would 'do
what is best' in both situations.

James

On Apr 1, 2005 3:00 AM, Rob Harrop <ro...@ca...> wrote:
> What about scoping - how will this be handled by the storage interface?
> 
> Rob
> 
> Keith Donald wrote:
> 
> >Yes, so a HttpSessionFlowExecutionStorage would use the HttpSession, a
> >HttpRequestFlowExecutionStorage would use the request, for example.  The
> >latter would also have to know how to reconstruct the FlowExecution soley
> >from the request parameters, while the former would just pull an existing
> >instance from the HttpSession given the flowExecutionId in the input Event.
> >
> >Keith
> >
> >-----Original Message-----
> >From: spr...@li...
> >[mailto:spr...@li...] On Behalf Of
> >Seth Ladd
> >Sent: Thursday, March 31, 2005 7:56 PM
> >To: spr...@li...
> >Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
> >Feedback needed
> >
> >On Thu, 31 Mar 2005 19:46:42 -0500, Keith Donald <ke...@in...>
> >wrote:
> >
> >
> >>Seth,
> >>
> >>Excellent idea.
> >>
> >>If we extract an interface from the HttpServletExecutionManager, we get
> >>something like:
> >>
> >>public interface FlowExecutionStorage {
> >>    public FlowExecution loadFrom(Event inputEvent);
> >>    public void saveOrUpdate(FlowExecution flowExecution);
> >>    public void remove(FlowExecution flowExecution);
> >>}
> >>
> >>Or something like that.  Erwin what do you think? Need to think about it
> >>more.  I imagine here the FlowExecutionStack would have to be
> >>
> >>
> >reconstructed
> >
> >
> >>from the Event parameters, for example: http request parameters, in an
> >>
> >>
> >http
> >
> >
> >>servlet environment.  It also has to be rehydrated with services on
> >>deserialization as well, including the FlowLocator and its
> >>FlowExecutionListenerList.
> >>
> >>
> >
> >
> >Keith,
> >
> >Just so I'm clear... this isn't to replace the concept and purpose of
> >the HttpSession?  This is just to provide a way to get the state info
> >of the flow into the request to avoid the need for session creation?
> >
> >Thanks!
> >Seth
> >
> >
> >-------------------------------------------------------
> >This SF.net email is sponsored by Demarc:
> >A global provider of Threat Management Solutions.
> >Download our HomeAdmin security software for free today!
> >http://www.demarc.com/info/Sentarus/hamr30
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >-------------------------------------------------------
> >This SF.net email is sponsored by Demarc:
> >A global provider of Threat Management Solutions.
> >Download our HomeAdmin security software for free today!
> >http://www.demarc.com/info/Sentarus/hamr30
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
> >
> >
> 
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

[Rob H. <ro...@ca...>]

What about scoping - how will this be handled by the storage interface?

Rob

Keith Donald wrote:

>Yes, so a HttpSessionFlowExecutionStorage would use the HttpSession, a
>HttpRequestFlowExecutionStorage would use the request, for example.  The
>latter would also have to know how to reconstruct the FlowExecution soley
>from the request parameters, while the former would just pull an existing
>instance from the HttpSession given the flowExecutionId in the input Event.
>
>Keith
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...] On Behalf Of
>Seth Ladd
>Sent: Thursday, March 31, 2005 7:56 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
>Feedback needed
>
>On Thu, 31 Mar 2005 19:46:42 -0500, Keith Donald <ke...@in...>
>wrote:
>  
>
>>Seth,
>>
>>Excellent idea.
>>
>>If we extract an interface from the HttpServletExecutionManager, we get
>>something like:
>>
>>public interface FlowExecutionStorage {
>>    public FlowExecution loadFrom(Event inputEvent);
>>    public void saveOrUpdate(FlowExecution flowExecution);
>>    public void remove(FlowExecution flowExecution);
>>}
>>
>>Or something like that.  Erwin what do you think? Need to think about it
>>more.  I imagine here the FlowExecutionStack would have to be
>>    
>>
>reconstructed
>  
>
>>from the Event parameters, for example: http request parameters, in an
>>    
>>
>http
>  
>
>>servlet environment.  It also has to be rehydrated with services on
>>deserialization as well, including the FlowLocator and its
>>FlowExecutionListenerList.
>>    
>>
>
>
>Keith,
>
>Just so I'm clear... this isn't to replace the concept and purpose of
>the HttpSession?  This is just to provide a way to get the state info
>of the flow into the request to avoid the need for session creation?
>
>Thanks!
>Seth
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by Demarc:
>A global provider of Threat Management Solutions.
>Download our HomeAdmin security software for free today!
>http://www.demarc.com/info/Sentarus/hamr30
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by Demarc:
>A global provider of Threat Management Solutions.
>Download our HomeAdmin security software for free today!
>http://www.demarc.com/info/Sentarus/hamr30
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

[Rob H. <ro...@ca...>]

Exactly what we are doing :)

Alef Arendsen wrote:

> I'm not sure, but when I used this approach I simply serialized 
> everything I needed, encoded it to a String Base64 String and put it 
> in a hidden input field. Of course not the most efficient way to do 
> it, but you don't have to worry about keeping your serialization 
> 'protocol' up-to-date. It will be a bit much maybe if you have many 
> subflows as you're saying?
>
> regards,
> Alef
>
>
> -----Original Message-----
> From: spr...@li... on behalf 
> of Keith Donald
> Sent: Fri 4/1/2005 1:00 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] SWF - Creating HTTP sessions 
> - Feedback needed
>
> Just thinking out loud here, but no, I don't think this would be too
> difficult to implement.  There is potentially lot to serialize out on each
> request, though, particularly if you a flow execution that has spawned 
> many
> nested subflows.
>
> Methinks we could have custom tag that serializes the 
> FlowExecutionStack on
> each request.  This would include serializing:
> - The ID of the flow execution (randomly generated guid)
> - The stack of IDs of all spawned flows, the top being the active flow and
> the rest any suspended parent flows (if the active flow is a subflow)
> - For each flow in the stack, everything in 'flow scope'.
>
> This does introduce the issue of having to convert from string
> representations of objects in flow scope on each request, possibly 
> applying
> automatic type conversion from attribute metadata (e.g from string ->
> number).  Do you know how this issue is handled in ASP.NET and JSF?
>
> Currently FlowExecution storage responsibility is externalized from 
> the core
> web.flow system -- the FlowExecutionStack, the central object for starting
> and manipulating a single client instance of a top-level flow, is a safely
> serializable memento.  The HttpServletFlowExecutionManager, by 
> default, uses
> HTTP session storage, but the get(..), save(..) and remove(...) 
> methods that
> accomplish this could be overridden to serialize to some other place 
> like a
> database.
>
> A custom HttpServletFlowExecutionManager subclass would likely need to be
> written to accomplish deserializing flow state in a hidden form back to a
> fully constructed FlowExecutionStack on each request.  One issue is 
> whether
> it makes sense to refactor this class given that need, and if so how.
>
> Keith
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On 
> Behalf Of
> Alef Arendsen
> Sent: Thursday, March 31, 2005 4:44 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
> Feedback needed
>
> It's what ASP.NET (and I think some JSF implementations) does as well -
> serialization of the state in a hidden input field. I don't think it'd
> be that difficult to implement a custom tag that does this, wouldn't
> it?
>
> rgds,
> Alef
>
> On Mar 31, 2005, at 10:30 PM, Rob Harrop wrote:
>
> > I see no problem in implictly creating a session - although I am
> > concerned about the impact of this on clustered applications. Can the
> > session implementation be factored out so that users can implement
> > their own session storage?
> >
> > Rob
> >
> > Erwin Vervaet wrote:
> >
> >> The Spring Web Flow (SWF) FlowController forces the "requireSession"
> >> property it inherits from AbstractController to "true". This is
> >> logical since the webflow system needs to store flow execution state
> >> in the HTTP session.
> >>
> >> So far so good. However, since the controller now requires an
> >> existing session, the user/developer is responsible for creating that
> >> session before a flow is started. This is typically not a problem in
> >> real-life applications since those carefully manage session creation
> >> and invalidation.
> >>
> >> Still, we are wondering whether it is a good idea to implicitly
> >> create sessions (usually using request.getSession()) in a controller,
> >> or should this be left as a responsability of the application
> >> developer? Note that AbstractWizardFormController and
> >> AbstractFormController implicitly create sessions.
> >>
> >> Erwin Vervaet
> >> erw...@er...
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.net email is sponsored by Demarc:
> >> A global provider of Threat Management Solutions.
> >> Download our HomeAdmin security software for free today!
> >> http://www.demarc.com/info/Sentarus/hamr30
> >> _______________________________________________
> >> Springframework-developer mailing list
> >> Spr...@li...
> >> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by Demarc:
> > A global provider of Threat Management Solutions.
> > Download our HomeAdmin security software for free today!
> > http://www.demarc.com/info/Sentarus/hamr30
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>

Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

[J. E. R. <er...@di...>]

Hi all,

We think it is a great idea that contributes to do SWF more independent 
from
the framework used, Portlets, Struts, etc.

The biggest problem that we have encountered to use a unique 
FlowExecutionManager
from Spring PortletMVC has been the manner to store/load the FlowExecution.

With this new interface should be easy to implement an 
AbstractFlowExecutionManager, or a FlowExecutionManager that delegates on
FlowExecutionStorage strategy (depends on the design pattern used).

Regards.

> +1
>
> We'll have to look into how difficult this would be to implement.
>
> Storing the flow execution state in the request could also make web 
> flows usable in situations
> where you have back-button/refresh-button issues.
>
> This would also allow us to implement a "continuation like" flow 
> execution system: clone the
> flow execution for every request, generate a unique id for each clone 
> and put that id in the request and
> the flow execution clone is some storage somewhere. That way the flow 
> execution effectively
> becomes a continuation! This would also solve most 
> back-button/refresh-button issues, but
> is ofcourse memory intensive.
>
> Erwin Vervaet
> erw...@er...
> ----- Original Message ----- From: "Keith Donald" <ke...@in...>
> To: <spr...@li...>
> Sent: Friday, April 01, 2005 2:46 AM
> Subject: RE: [Springframework-developer] SWF - Creating HTTP sessions 
> - Feedback needed
>
>
>> Seth,
>>
>> Excellent idea.
>>
>> If we extract an interface from the HttpServletExecutionManager, we get
>> something like:
>>
>> public interface FlowExecutionStorage {
>>    public FlowExecution loadFrom(Event inputEvent);
>>    public void saveOrUpdate(FlowExecution flowExecution);
>>    public void remove(FlowExecution flowExecution);
>> }
>>
>> Or something like that.  Erwin what do you think? Need to think about it
>> more.  I imagine here the FlowExecutionStack would have to be 
>> reconstructed
>> from the Event parameters, for example: http request parameters, in 
>> an http
>> servlet environment.  It also has to be rehydrated with services on
>> deserialization as well, including the FlowLocator and its
>> FlowExecutionListenerList.
>>
>> Keith
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...] On 
>> Behalf Of
>> Seth Ladd
>> Sent: Thursday, March 31, 2005 6:21 PM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
>> Feedback needed
>>
>> On Thu, 31 Mar 2005 17:49:24 -0500, Keith Donald <ke...@in...>
>> wrote:
>>
>>> Just thinking out loud here, but no, I don't think this would be too
>>> difficult to implement.  There is potentially lot to serialize out 
>>> on each
>>> request, though, particularly if you a flow execution that has spawned
>>
>> many
>>
>>> nested subflows.
>>>
>>> Methinks we could have custom tag that serializes the 
>>> FlowExecutionStack
>>
>> on
>>
>>> each request.  This would include serializing:
>>> - The ID of the flow execution (randomly generated guid)
>>> - The stack of IDs of all spawned flows, the top being the active 
>>> flow and
>>> the rest any suspended parent flows (if the active flow is a subflow)
>>> - For each flow in the stack, everything in 'flow scope'.
>>
>>
>> Keith,
>>
>> Sounds like there might be two Strategies here for storing the
>> FlowExecutionStack: HttpSession Strategy and HttpRequest Strategy.
>> The developer can then choose the strategy for their needs, as there
>> are good use cases for not requiring a session.
>>
>> Seth
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by Demarc:
>> A global provider of Threat Management Solutions.
>> Download our HomeAdmin security software for free today!
>> http://www.demarc.com/info/Sentarus/hamr30
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by Demarc:
>> A global provider of Threat Management Solutions.
>> Download our HomeAdmin security software for free today!
>> http://www.demarc.com/info/Sentarus/hamr30
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>


-- 
J.Enrique Ruiz
Director de I+D+I - DiSiD S.L.L. (http://www.disid.com)
Tel +34 655 407 965
Email: er...@di...

[Springframework-developer] spring Build Failed

[<al...@jt...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050401103520

Re: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

[Erwin V. <erw...@er...>]

+1

We'll have to look into how difficult this would be to implement.

Storing the flow execution state in the request could also make web flows 
usable in situations
where you have back-button/refresh-button issues.

This would also allow us to implement a "continuation like" flow execution 
system: clone the
flow execution for every request, generate a unique id for each clone and 
put that id in the request and
the flow execution clone is some storage somewhere. That way the flow 
execution effectively
becomes a continuation! This would also solve most 
back-button/refresh-button issues, but
is ofcourse memory intensive.

Erwin Vervaet
erw...@er...
----- Original Message ----- 
From: "Keith Donald" <ke...@in...>
To: <spr...@li...>
Sent: Friday, April 01, 2005 2:46 AM
Subject: RE: [Springframework-developer] SWF - Creating HTTP sessions - 
Feedback needed


> Seth,
>
> Excellent idea.
>
> If we extract an interface from the HttpServletExecutionManager, we get
> something like:
>
> public interface FlowExecutionStorage {
>    public FlowExecution loadFrom(Event inputEvent);
>    public void saveOrUpdate(FlowExecution flowExecution);
>    public void remove(FlowExecution flowExecution);
> }
>
> Or something like that.  Erwin what do you think? Need to think about it
> more.  I imagine here the FlowExecutionStack would have to be 
> reconstructed
> from the Event parameters, for example: http request parameters, in an 
> http
> servlet environment.  It also has to be rehydrated with services on
> deserialization as well, including the FlowLocator and its
> FlowExecutionListenerList.
>
> Keith
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf 
> Of
> Seth Ladd
> Sent: Thursday, March 31, 2005 6:21 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
> Feedback needed
>
> On Thu, 31 Mar 2005 17:49:24 -0500, Keith Donald <ke...@in...>
> wrote:
>> Just thinking out loud here, but no, I don't think this would be too
>> difficult to implement.  There is potentially lot to serialize out on 
>> each
>> request, though, particularly if you a flow execution that has spawned
> many
>> nested subflows.
>>
>> Methinks we could have custom tag that serializes the FlowExecutionStack
> on
>> each request.  This would include serializing:
>> - The ID of the flow execution (randomly generated guid)
>> - The stack of IDs of all spawned flows, the top being the active flow 
>> and
>> the rest any suspended parent flows (if the active flow is a subflow)
>> - For each flow in the stack, everything in 'flow scope'.
>
> Keith,
>
> Sounds like there might be two Strategies here for storing the
> FlowExecutionStack: HttpSession Strategy and HttpRequest Strategy.
> The developer can then choose the strategy for their needs, as there
> are good use cases for not requiring a session.
>
> Seth
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
> 

RE: [Springframework-developer] SWF - Creating HTTP sessions - Feedback needed

[Alef A. <al...@jt...>]

I'm not sure, but when I used this approach I simply serialized =
everything I needed, encoded it to a String Base64 String and put it in =
a hidden input field. Of course not the most efficient way to do it, but =
you don't have to worry about keeping your serialization 'protocol' =
up-to-date. It will be a bit much maybe if you have many subflows as =
you're saying?

regards,
Alef


-----Original Message-----
From: spr...@li... on behalf of =
Keith Donald
Sent: Fri 4/1/2005 1:00 AM
To: spr...@li...
Subject: RE: [Springframework-developer] SWF - Creating HTTP sessions - =
Feedback needed
=20
Just thinking out loud here, but no, I don't think this would be too
difficult to implement.  There is potentially lot to serialize out on =
each
request, though, particularly if you a flow execution that has spawned =
many
nested subflows.

Methinks we could have custom tag that serializes the FlowExecutionStack =
on
each request.  This would include serializing:
- The ID of the flow execution (randomly generated guid)
- The stack of IDs of all spawned flows, the top being the active flow =
and
the rest any suspended parent flows (if the active flow is a subflow)
- For each flow in the stack, everything in 'flow scope'.

This does introduce the issue of having to convert from string
representations of objects in flow scope on each request, possibly =
applying
automatic type conversion from attribute metadata (e.g from string ->
number).  Do you know how this issue is handled in ASP.NET and JSF?

Currently FlowExecution storage responsibility is externalized from the =
core
web.flow system -- the FlowExecutionStack, the central object for =
starting
and manipulating a single client instance of a top-level flow, is a =
safely
serializable memento.  The HttpServletFlowExecutionManager, by default, =
uses
HTTP session storage, but the get(..), save(..) and remove(...) methods =
that
accomplish this could be overridden to serialize to some other place =
like a
database.

A custom HttpServletFlowExecutionManager subclass would likely need to =
be
written to accomplish deserializing flow state in a hidden form back to =
a
fully constructed FlowExecutionStack on each request.  One issue is =
whether
it makes sense to refactor this class given that need, and if so how.

Keith
=20
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Alef Arendsen
Sent: Thursday, March 31, 2005 4:44 PM
To: spr...@li...
Subject: Re: [Springframework-developer] SWF - Creating HTTP sessions -
Feedback needed

It's what ASP.NET (and I think some JSF implementations) does as well -=20
serialization of the state in a hidden input field. I don't think it'd=20
be that difficult to implement a custom tag that does this, wouldn't=20
it?

rgds,
Alef

On Mar 31, 2005, at 10:30 PM, Rob Harrop wrote:

> I see no problem in implictly creating a session - although I am=20
> concerned about the impact of this on clustered applications. Can the=20
> session implementation be factored out so that users can implement=20
> their own session storage?
>
> Rob
>
> Erwin Vervaet wrote:
>
>> The Spring Web Flow (SWF) FlowController forces the "requireSession"=20
>> property it inherits from AbstractController to "true". This is=20
>> logical since the webflow system needs to store flow execution state=20
>> in the HTTP session.
>>
>> So far so good. However, since the controller now requires an=20
>> existing session, the user/developer is responsible for creating that =

>> session before a flow is started. This is typically not a problem in=20
>> real-life applications since those carefully manage session creation=20
>> and invalidation.
>>
>> Still, we are wondering whether it is a good idea to implicitly=20
>> create sessions (usually using request.getSession()) in a controller, =

>> or should this be left as a responsability of the application=20
>> developer? Note that AbstractWizardFormController and=20
>> AbstractFormController implicitly create sessions.
>>
>> Erwin Vervaet
>> erw...@er...
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by Demarc:
>> A global provider of Threat Management Solutions.
>> Download our HomeAdmin security software for free today!
>> http://www.demarc.com/info/Sentarus/hamr30
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by Demarc:
> A global provider of Threat Management Solutions.
> Download our HomeAdmin security software for free today!
> http://www.demarc.com/info/Sentarus/hamr30
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>



-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer