Hi Carlin,
Thank you for you quick and valuable response. This is a beauty of working
with an open-source project.
Now, to the business! I?ll try to elaborate a little bit more about the
issues, so I?m sure we are thinking about the same thing.
(1) Basically, what I?m looking is a possibility to restrict a set of
methods that are possible to call from any given JSP. Ideally, I would
also like to change a navigation model from JSPs, so I don?t have to
specify a concrete action name, but a logical event name. <Disclaimer> I
know that I?m asking about the substantial change in the way Beehive works
currently, but maybe it is sth worth considering??? </Disclaimer>. Now, to
achieve both goals (restricted set of actions from JSPs and calls from
JSPs by specifying an event name, not an action name), we could do 2
things:
a) Equip a simple action with the set of forwards, just like method
actions do have forwards (this is what I meant by forwards from JSPs,
sorry for failing to communicate this?.). Example would be:
simpleActions = {
@Jpf.SimpleAction(name = "begin", path =
"index.jsp",
forwards = {
@Jpf.Forward(name = "success", action="actionName")})
})
b) Change the standard <netui:anachor/> tag, to have an attribute
called ?event? (or sth similar), instead of an action name. This event
name should correspond to the forward name defined in a simple action (see
example above).
I know I?m proposing a huge change, and I know there is Struts under the
cover, so those changes may not be possible. But - maybe there is a
work-around to achieve the same result?
I think that adding the proposed changes also would allow the creation of
visual flow editor ? this is rather hard at the moment?
(2) Yes, I?m aware about the href attribute in the netui:anachor tag,
but it still means hard-coding ?.do? extensions in JSP, right? What I
would really like to see is netui:anachor taking two attributes:
controller (page flow) name and action / event name.
(3) Problem with JavaScript: I?m working on the huge application,
already in production for several years. There is a lot of dynamic
JavaScript behavior, in form of in-house developed libraries. There are
functions that take a form object as a parameter and play with form
fields, referring to those fields by name. I assume this code would break
immediately, when introducing Beehive. This is something no one is willing
to accept?
Just out of curiosity: why is scoping of form field names needed at all???
I understand that we need to scope target name (POST action), but why to
scope form field names??? I?m probably missing the obvious, but?
(4) So, do you think it would be possible to add this feature (I mean,
forwards inheritance with merge)? For me, without this feature, flow
inheritance is loosing a lot from its potential. I can provide concrete
examples to illustrate this point, if you are willing to consider this
feature in the features releases of Beehive.
So, to sum up: I know I?m asking about things that may not be available in
Beehive right know. Even so, I would like to know if there are other
solutions.
I strongly believe there is a room for the flow library like Beehive,
where you can express your flow design in a Java + annotations code.
Unfortunately, it seams that because of the issues just described I can?t
use it in my project. Maybe I?m wrong and there is some kind of an
alternative solution.
Best regards,
Pawel Kozlowski
