Oh sure, it could, but who is going to develop it?
On 27-nov-05, at 02:07, Keith Lea wrote:
A static analysis tool or IDE could certainly show you all possible
flows through the application, unless some funny dynamic
instantiation method were used.
On Nov 26, 2005, at 6:41 PM, Geert Bevin wrote:
Hi Keith,
this goes against one of the basic ideas of the framework: the
site structure gives a complete overview over the flow of your
application. By reading it you know exactly which elements
participate and how they interconnect
Declaring your flow fully inside your classes makes a developer
read your entire application code before being able to see how
everything interconnects. It might maybe benefit you at one
particular moment since you don't have to write one additional
line in the site structure, however your code will be come much
less maintainable. Even that is not entirely true, since you're
also adding the @Entry annotation to the target element, which has
you changing something somewhere anyway.
Best regards,
Geert
On 26-nov-05, at 22:52, Keith Lea wrote:
I'm sick of having to edit the site xml to add a new exit, then a
flowlink for it. I think exiting should be as simple as a method
call, and exits should not be to an element by its id, but to a
class by its FQN.
I wonder what others on this list think of the idea.
I think RIFE should use bytecode transformation to allow a simple
method call to exit from one element to another.
class First extends Element {
void processElement() {
if (hasSubmission(..)) { .. do some form stuff }
String someFormValue = ...;
new Second().jump(someFormValue);
}
}
class Second extends Element {
String something;
@Entry void jump(String thatValue) {
something = thatValue;
}
void processElement() {
print(something);
}
}
I think this would be great. RIFE bytecode manipulation could
make it so the jump() call actually exited after jump returned.
Such behavior would happen for any call of a method labelled @Entry.
This could even be elegant for producing URL's, like:
Second second = new Second().jump("something");
t.setValue("user_url", second.getUrl());
For this to work, maybe jump() should not be bytecode-modified to
halt execution, but instead to set a flag within RIFE engine to
tell it to exit, once processElement returns.
Another idea could be to not use bytecode manipulation at all,
but instead change "exit" method to accept any instance of Element.
What does everyone think of this?
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
--
Geert Bevin Uwyn bvba
"Use what you need" Avenue de Scailmont 34
http://www.uwyn.com 7170 Manage, Belgium
gbevin[remove] at uwyn dot com Tel +32 64 84 80 03
PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
--
Geert Bevin Uwyn bvba
"Use what you need" Avenue de Scailmont 34
http://www.uwyn.com 7170 Manage, Belgium
gbevin[remove] at uwyn dot com Tel +32 64 84 80 03
PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
_______________________________________________
Rife-users mailing list
[email protected]
http://www.uwyn.com/mailman/listinfo/rife-users
