Hi Ricardo,

I've got an answer for #1 -- someone else would be better suited for #2.

Ricardo Constantino wrote:

>Hi,
>
>I have the same problem, but i already found some more issues:
>
> 1) The pageflow only allow the usage of jsp that are in same directory of
>the pageflow file, this issue gives some problems with the jsp reuse;
>  
>
In NetUI, there definitely is a bond between pages and page flows.  In
general, this means that applications are comprised of cleanly-separated
pieces (the page flows, each of which consists of a single controller
and any number of pages).  But this doesn't prevent reuse!  There are
two major vehicles for reuse in NetUI:

    - Nested page flows.  These are *entire flows* that can be used in
the middle of other flows.  In the tiniest case, you could have a nested
page flow that contains only a single controller and a single page, and
use that from many other page flows... but often the unit of reuse is
bigger than a single page.  See
http://beehive.apache.org/docs/1.0/netui/nestedPageFlow.html for more
information about this.

Nested page flows are a recognition of the fact that often you want to
reuse both pages *and* controller logic, and that keeping these two
things tied together in a clear way makes for cleaner, more
understandable apps.

    - Page templates.  When you want to share *pieces* of other JSPs,
you can use templates
(http://beehive.apache.org/docs/1.0/netui/tagsTemplate.html ).  NetUI
also supports Tiles if you're familiar with that.

I'd be happy to provide more information on this; let me know if you've
got other questions/concerns.

Rich

> 2) There are some problems using more than 1 database controller in the
>same transaction, since each controller creates an database connection.
>Since i only want to use 1 connection per user thread, i can't use more that
>1 database controller. So i need to have 1 big database controller with all
>aplication database acess.
>  
>
>Thanks,
>Ricardo Constantino
>
>
>On 12/2/05, Beohar, Vaibhav <[EMAIL PROTECTED]> wrote:
>  
>
>>Hi Guys,
>>
>>I have a set of questions that I need to get clarified before I can put
>>forth a proposal of implementing Beehive in my company's web based project
>>(If I do propose the usage of Beehive and if there are problems later on,
>>I'm the one who's going to get a lot of flak for it), so please do help.
>>
>>The application is an N Tier web-application with current proposal of
>>using
>>Struts, Validation framework (with both user defined validations and the
>>ones included in validation-rules.xml), DynaActionFormBeans etc. for
>>front-end and session façade, service locater, helper classes etc. in the
>>middle tier and Stateless session beans and Abstract Factory DAOs for the
>>back end.
>>1)      One of the chief reasons for the scepticism over Beehive is that
>>folks think that Beehive splits the controller (in different controller
>>files) which makes the effort of tracking from one flow to other that more
>>tough. Whereas Struts has a central struts-config.xml file which can be
>>easily used for tracking the flow, there is no such single file in Beehive
>>and this could lead to more time in tracking the flows than in Struts.
>>2)      Beehive does not have a configuration file which could be changed
>>without the need for compilation. Such files go a long way in meeting
>>customer demands in case of a quick business flow change. For example, in
>>Struts a change in scenario A to scenario B [JSP flow] will be so easily
>>changeable by tweaking some tags in struts-config.xml here and there,
>>whereas in Beehive the same activity may lead to multiple sub-activities
>>like tracking the flow in individual Java Controller files, changing the
>>Java code and their subsequent compilation.
>>3)      Can we make DynaActionFormBeans in Beehive or do we have to make
>>explicit Java Beans as form beans each time a flow is decided.
>>4)      Can we use a validation framework with user defined validations.
>>5)      How easy or tough is the task of rendering internationalized
>>message
>>in Beehive.
>>Thanks,
>>Vaibhav
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>    
>>
>
>  
>

Reply via email to