Thanks for this explanation.
It is clearer for me now.
What changes when we add the <state storage="session"> stuff?
Have a good week end.
jean-marie
Geert Bevin wrote:
>
> Hi Jean-Marie,
>
> this is a very good question and there isn't enough information about
> this.
>
> RIFE is very different with regards to external state handling than
> anything else out there (note that this has nothing to do with
> internal state handling like continuations). One of the basic ideas
> is that the you should be able to develop a stateful application
> without any server-side state. To be able to do this, the significant
> state should be able to be transfered through the client-side with
> query parameters, hidden form parameters or a structured pathinfo.
> Therefore, the state needs to be distilled and also always be
> representable as a concise string. Initially, RIFE didn't have any
> support for inputs and output injection / outjection for elements and
> you always had to explicitly call getInput and setOutput.
>
> A few versions ago we added support for bijection, which leads you to
> expect that the state will just be preserved in a session. However,
> the same rules apply as before. I think we still need to do some fine-
> tuning though to warn people when inputs / outputs aren't usable due
> to the string conversion that happens in between and maybe to add
> some features that allow you to reconstitute more complex data
> structures from a string representation (any suggestions here are
> welcome).
>
> The input beans and output beans are shortcuts, as with all bean
> handling in RIFE. It automatically goes over all the bean properties
> and treats them as individual inputs / outputs. Being able to name
> them makes it easy when you want to explicitly retrieve the beans
> (getInputBean) and you declared them to use prefixes, for instance.
>
> You can however opt to work with more complex objects as input /
> outputs, but currently you'll have to call setOutput(Object) and
> getInputSerializable(String) explicitly. It should be possible to
> adopt this also for injection/outjection, but think that it's
> dangerous to do by default since it's too easy to pollute your state
> with very large serialized objects. Maybe this should be added as an
> attribute to the @InputProperty and @OutputProperty annotations. What
> do you think?
>
> Hope this sheds some light on this. Note that if you want very
> statefull server-side handling of state, continuations are a bette
> choice.
>
> Take care,
>
> Geert
>
> On 13 Jan 2007, at 16:33, Jean-Marie Galliot wrote:
>
>> In this example :
>>
>> <element implementation="com.test.Start"
>> <input name="var1" />
>> <output name="var1" />
>>
>> What can be the type of var1?
>>
>> Only primitive? (int, float, String ...)
>>
>> What happens if it corresponds to property setters and getters like
>> these
>>
>> public MyType getVar1() {
>> return var1
>> }
>>
>> public void setGame(MyType var1) {
>> this.var1 = var1;
>> }
>>
>> MyType being a custom class in my project (bean) ?
>>
>> I tried it and the property is always set with a null argument.
>>
>> I saw that there is another element
>>
>> <outbean ...
>>
>> Must we always use it when we want to transmit anything but primitive
>> values?
>>
>> If this is correct I am wondering why there is two syntaxes (output
>> and
>> outbean). We could discover the type of the property by
>> introspection or
>> supply it with the classname attribute like in <outbean>?
>>
>> Now, if I use <outbean>/<inbean> I should not use matching getters and
>> setters like above? but rather getNameInputBean/setNameOutputBean?
>>
>> But in this case I have to call them myself in processElement for
>> example. I
>> don't have anymore the "callback" kind of facility that simple
>> getters/setters offer for primitive values?
>>
>> I don't know if this is very clear.
>>
>> Please note it is not criticism. I am sure there are very good reasons
>> behind that. When I will understand them better, I will be a better
>> Rife
>> programmer :-)
>>
>> Tks
>>
>> jean-marie
>>
>>
>> --
>> View this message in context: http://www.nabble.com/More-about-
>> datalinks-tf2971533.html#a8315046
>> Sent from the RIFE - users mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Rife-users mailing list
>> [email protected]
>> http://lists.uwyn.com/mailman/listinfo/rife-users
>>
>
> --
> Geert Bevin
> Uwyn "Use what you need" - http://uwyn.com
> RIFE Java application framework - http://rifers.org
> Music and words - http://gbevin.com
>
>
> _______________________________________________
> Rife-users mailing list
> [email protected]
> http://lists.uwyn.com/mailman/listinfo/rife-users
>
>
--
View this message in context:
http://www.nabble.com/More-about-datalinks-tf2971534.html#a8349368
Sent from the RIFE - users mailing list archive at Nabble.com.
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
