Beehive issues

[Pawel Kozlowski <pk...@amadeus.com>]

Hi All,

Recently I was evaluating BEA?s Portal v9.2 and - of course ? Apache 
Beehive as part of it. During the investigation I?ve run into several 
serious issues I would like to discuss on the list. I don?t want to jump 
to unfair conclusions in my closing report? maybe I?ve missed something? 
So, I would be really grateful for any feedback regarding the issues 
described below:

1)      Inconsistent navigation model. From what I could understand, you 
can navigate from a method action only by going through forwards (either 
method-level or global ones). You do this navigation by specifying a 
logical ?event name? (forward name). On the other hand, in JSP (?view 
node?) you are free to call any action, even the one not intended by a 
flow designer! In fact, this is possible, because in JSP you do specify an 
action name not a logical event name! What it effectively means is that 
you can?t express a restriction like ?from this JSP (presentation node) 
you can only call certain actions?. I can?t find an equivalent of forwards 
on the JSP level. Because of this, Beehive seams to capture only half of a 
logical web flow, and should be placed somewhere between ?simple? web 
frameworks (Struts, WebWork) and ?real? web flow libraries (Spring Web 
Flow). Am I right or missing sth obvious? What I would like to see is sth 
like forwards for simple (annotation) actions, and different set of 
taglibs, where you specify a forward name, not an action name. 

2)      Taglib - links to other flows ? I couldn?t find a JSP tag that 
would allow me to create links to other web flow controllers. This is 
because I use an action name while constructing a link, without a 
controller name! Of course I could create a link manually, but it would 
mean hard-coding a link pattern in JSPs, and this should be responsibility 
of taglib.

3)      Taglib ? different field names and Java Script ? it seams that 
Beehive taglibs used to create form fields, do add a prefix to a generated 
HTML form field name. Worse yet, those prefixes are different in a 
stand-alone and portal environment. Unpredictable field names make it very 
difficult to add sophisticated JavaScript?

4)      Flow inheritance ? at first it seemed like a wonderful feature, 
but in practice it turned out to be almost useless, since some annotations 
(method forwards) are not inherited from a parent class. What I would like 
to see is kind of merging for forwards ? or at least a way to specify, if 
I want method forwards to be overridden or merged in a child class. I 
asked about this in a separate thread (post from Thu, 08 Jun, 14:27), but 
got no response?.

Please, help me with the evaluation of Beehive. I would like to propose 
this solution, as it is very well integrated with BEA portal. 
Unfortunately, because of identified issues I can?t recommend using 
Beehive. I hope I?ve missed some obvious solution / work-around for 
problems just described.

Best regards,
Pawel Kozlowski

Re: Beehive issues

[Carlin Rogers <ca...@gmail.com>]

Hi Pawel,

Thanks for the observations. I'll try to provide some feedback to the
questions you've raised from your investigation.

1) I'm not sure I fully understand what you're after here. You're correct
that there's not a mechanism to restrict the set of actions a JSP can use.
The page flow simple actions let you just forward from one JSP to the next
(think of it like a Struts ForwardAction). I guess I'm missing the
explanation for having a JSP refer to a forward.

2) The NetUI anchor tags include an href attribute as an alternative to the
action attribute.  This allows you to create links to actions in other page
flows. So using a relative path you might have a tag something like...

<netui:anchor href="../pageflowpath/myaction.do">text
</netui:anchor>

or using the context path...

<netui:anchor href="${pageContext.request.contextPath
}/pageflowpath/myaction.do">text
</netui:anchor>

Maybe this would solve the problem?

3) In general, NetUI page flows and tags do not have any knowledge that they
are running in a portal environment. The Beehive framework has provided
mechanisms to facilitate portlet scoping including with the tags the prefix
used to scope the fields of a form to a portlet. The NetUI javascript
includes routines for finding the form fields without having to know the
prefix. The prefix is intended as an implementation detail. Are you having
problems with lookupIdByTagId(), or is it an issue between using the
<netui:html> vs <netui:scriptContainer>?

4) I don't think the inheritance implementation for @Action annotation of a
controller method will merge the set of forwards. One workaround would be to
define your base controller action so that it is not abstract and with the
set forwards you want and have it call another abstract method. Then the
derived controller class could just implement the base class abstract
method.

I hope this helps a little.

Kind regards,
Carlin

On 8/18/06, Pawel Kozlowski <pk...@amadeus.com> wrote:
>
> Hi All,
>
> Recently I was evaluating BEA?s Portal v9.2 and - of course ? Apache
> Beehive as part of it. During the investigation I?ve run into several
> serious issues I would like to discuss on the list. I don?t want to jump
> to unfair conclusions in my closing report? maybe I?ve missed something?
> So, I would be really grateful for any feedback regarding the issues
> described below:
>
> 1)      Inconsistent navigation model. From what I could understand, you
> can navigate from a method action only by going through forwards (either
> method-level or global ones). You do this navigation by specifying a
> logical ?event name? (forward name). On the other hand, in JSP (?view
> node?) you are free to call any action, even the one not intended by a
> flow designer! In fact, this is possible, because in JSP you do specify an
> action name not a logical event name! What it effectively means is that
> you can?t express a restriction like ?from this JSP (presentation node)
> you can only call certain actions?. I can?t find an equivalent of forwards
> on the JSP level. Because of this, Beehive seams to capture only half of a
> logical web flow, and should be placed somewhere between ?simple? web
> frameworks (Struts, WebWork) and ?real? web flow libraries (Spring Web
> Flow). Am I right or missing sth obvious? What I would like to see is sth
> like forwards for simple (annotation) actions, and different set of
> taglibs, where you specify a forward name, not an action name.
>
> 2)      Taglib - links to other flows ? I couldn?t find a JSP tag that
> would allow me to create links to other web flow controllers. This is
> because I use an action name while constructing a link, without a
> controller name! Of course I could create a link manually, but it would
> mean hard-coding a link pattern in JSPs, and this should be responsibility
> of taglib.
>
> 3)      Taglib ? different field names and Java Script ? it seams that
> Beehive taglibs used to create form fields, do add a prefix to a generated
> HTML form field name. Worse yet, those prefixes are different in a
> stand-alone and portal environment. Unpredictable field names make it very
> difficult to add sophisticated JavaScript?
>
> 4)      Flow inheritance ? at first it seemed like a wonderful feature,
> but in practice it turned out to be almost useless, since some annotations
> (method forwards) are not inherited from a parent class. What I would like
> to see is kind of merging for forwards ? or at least a way to specify, if
> I want method forwards to be overridden or merged in a child class. I
> asked about this in a separate thread (post from Thu, 08 Jun, 14:27), but
> got no response?.
>
> Please, help me with the evaluation of Beehive. I would like to propose
> this solution, as it is very well integrated with BEA portal.
> Unfortunately, because of identified issues I can?t recommend using
> Beehive. I hope I?ve missed some obvious solution / work-around for
> problems just described.
>
> Best regards,
> Pawel Kozlowski
>