Return-Path: Delivered-To: apmail-beehive-user-archive@www.apache.org Received: (qmail 81610 invoked from network); 18 Aug 2006 21:57:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 18 Aug 2006 21:57:42 -0000 Received: (qmail 8468 invoked by uid 500); 18 Aug 2006 21:57:42 -0000 Delivered-To: apmail-beehive-user-archive@beehive.apache.org Received: (qmail 8174 invoked by uid 500); 18 Aug 2006 21:57:41 -0000 Mailing-List: contact user-help@beehive.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Beehive Users" Delivered-To: mailing list user@beehive.apache.org Received: (qmail 8163 invoked by uid 99); 18 Aug 2006 21:57:41 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Aug 2006 14:57:41 -0700 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_10_20,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of carlin.rogers@gmail.com designates 64.233.182.185 as permitted sender) Received: from [64.233.182.185] (HELO nf-out-0910.google.com) (64.233.182.185) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Aug 2006 14:57:40 -0700 Received: by nf-out-0910.google.com with SMTP id l37so1573093nfc for ; Fri, 18 Aug 2006 14:57:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Q+Hl6AUwoO65f2lSI0sMjybv4MTlf3hZXWTkfQUT4zdqMDvinPNkorYkia8lLwmBw4toHYRUSaqALTcLm7GZAo589mSNRUJ2IvCfttQKBYrdkMInwm97P74DKgPq9axevykqx3HurX36sw/m+LhhvtDxgJLUFQ9c7zJ3LnuTpx0= Received: by 10.48.162.15 with SMTP id k15mr4606778nfe; Fri, 18 Aug 2006 14:57:18 -0700 (PDT) Received: by 10.78.83.19 with HTTP; Fri, 18 Aug 2006 14:57:18 -0700 (PDT) Message-ID: Date: Fri, 18 Aug 2006 15:57:18 -0600 From: "Carlin Rogers" To: "Beehive Users" Subject: Re: Beehive issues In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9753_22421262.1155938238638" References: X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_9753_22421262.1155938238638 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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... text or using the context path... text 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 vs ? 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 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 > ------=_Part_9753_22421262.1155938238638--