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
Rife-users@uwyn.com
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
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
