beehive-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlin Rogers" <>
Subject Re: Beehive issues
Date Fri, 18 Aug 2006 21:57:18 GMT
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/">text

or using the context path...

<netui:anchor href="${pageContext.request.contextPath

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

I hope this helps a little.

Kind regards,

On 8/18/06, Pawel Kozlowski <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message