beehive-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Feit <>
Subject Re: Doubts on Apache Beehive.
Date Fri, 02 Dec 2005 17:17:37 GMT
Hi Vaibhav,

Some good questions here -- answers/comments inline.

Beohar, Vaibhav 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.
In Struts, you can actually split your configuration across multiple
"modules", with a separate configuration file for each module. 
Beehive's Page Flow is similar; you can create multiple controllers
("page flows") for different pieces of your application.  *** In both
Struts and Page Flow, you can create one single controller if that's
what you want. *** 

Beehive's Page Flow is actually much more centralized than Struts is,
since all configuration, actions, exception handlers and state related
to a controller are in a single file.  The best way to think about it is
that a page flow controller is like a Struts config file, but with all
controller-related Java code and state in the same place.

>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.
Beehive Page Flow generates Struts XML config files during compilation,
and you can certainly change these on the fly.  They're in
WEB-INF/classes/_pageflow/struts-config-*.xml.  Ultimately you'd need to
go back and change the annotations in the Java source file, but in the
Struts case you'd also have to go back and make equivalent changes in
your source repository.

Again, Page Flow doesn't force you into multiple controllers, although I
do feel that it's much better to break the app into smaller,
self-contained pieces.  :)

>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.
You can.  It involves creating a small Struts config file (containing
the dyna-form definition) that gets merged into the page flow
controller.  I've been meaning to add this to our samples; will try to
do that today and post it on this thread.

>4) 	Can we use a validation framework with user defined validations.
Yes, through the @Jpf.ValidateCustom annotation.  I'll try to add this
sample as well (should have this later today).

>5) 	How easy or tough is the task of rendering internationalized message
>in Beehive.
Easy.  :)  In a page flow controller, you'd add any number of
@Jpf.MessageBundle annotations,e.g.,

@Jpf.MessageBundle(bundlePath="messages.defaultMessages"),    // this is
the "default" message bundle -- not named

These point to /messages/ and
/messages/, respectively on classpath (just like in
the <message-resources> tag in Struts -- this is in fact what those
annotations turn into).  Then, in your JSPs, you'd bind to these
messages like this:

        This is a localized message: ${bundle.default.someMessage}
                - or -
        <netui:textBox defaultValue="${bundle.another.anotherMessage}"/>

Hope this helps; let me know if you need more info on any of this.  I'll
try to get those two samples done today.



View raw message