Hi Pawel,
Sorry for the delay in this response. Thanks for providing the additional
information and feedback. I have a few more comments based on my experience,
but maybe some others on the list will have additional thoughts or insight
to offer as well.
1) I think I understand what you're describing here. The crux of the problem
would be in restricting the set of actions a JSP could use. I don't know how
one would impose this on a JSP. It seems that within in the JSP you would
have to have knowledge of which action you wanted to use as multiple simple
actions could have the same forward names ("logical events"), right?
Otherwise, it would imply that the forward names would have to be unique
across the simple actions. If a user had the same names (which is allowed
today across method actions), then the runtime would not be able to
distinguish the forward. Something in the request would be needed to
identify the forward. This sort of implies having logic in the JSP... but
maybe I'm still missing something with this.
As an aside, have you looked at the conditionalForwards attribute for a
simple action. It allows you to have a couple of forward options for a given
simple action, based on a JSP 2.0-style expression evaluating to true. For
example, you could have a page flow property, page, that determined the JSP
to go to...
simpleActions={
@Jpf.SimpleAction(
name="conditional",
conditionalForwards={
@Jpf.ConditionalForward(
condition="${pageFlow.choice=='page1'}",
path="page1.jsp"),
@Jpf.ConditionalForward(
condition="${pageFlow.choice=='page2'}",
path="page2.jsp")
},
path="start.jsp"
)
}
I know this isn't the same as what you're after but maybe this would allow
you to achieve the flow you want without having logic in the JSP.
You mentioned having a "visual flow editor". Are you thinking of a page flow
"overview" that illustrated the flow between all the actions and pages of a
page flow in a graph? Just curious.
2) Yes, the href attribute requires the ".do" extension. I'm not aware of
any technical issues on this enhancement. You could post a specific message
for this on the dev alias to kick off a discussion or file an
enhancement/improvement in JIRA.
3) In the portal environment, the same page flow can be used in multiple
portlets within a portal page. Each page flow and the requests would be
scoped to the portlet. On the client side, javascript routines may need to
find form fields within a given portlet. The prefix keeps the fields unique
across multiple portlets that use the same page flow.
4) With inheritance, NetUI does support merging of the attributes on the
Controller annotation. However, the action level annotation completely
overrides. I think it would be difficult to know the user's intentions in
the case of an override (or implementation of the abstract method action).
For example, should a set of declarative validation properties override the
ones on the action in the base class or be merged? With a set of forwards it
seems OK to just make them additive and the developer would not use the ones
they did not override and didn't need. However, there could be a use case
where you would not want to inherit a specific validatable property. Could
you just use the global forwards (forwards on the Controller annotation) for
your app?
Again, I hope the comments help.
Kind regards,
Carlin
On 8/22/06, Pawel Kozlowski <[EMAIL PROTECTED]> wrote:
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
