beehive-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Beohar, Vaibhav" <>
Subject RE: Doubts on Apache Beehive.
Date Sat, 03 Dec 2005 08:05:26 GMT
Hi Everyone!
Thanks a lot for the great suggestions posted on this group for the thread.
Receiving so many amazing replies from y'all, has made my life that much
more easy :)

I had some more points to bring in here...
	1) As Rich said below -- breaking struts-config from a large
monolithic file into small modular struts-configs is also possible. Then --
		a) How is it done [breaking struts-config into smaller
modular files]? Can anyone point me to a link or code where it is shown to
be implemented.
		b) If it is possible, then whats the greater need for page
flows. I mean, looking from a greater perspective, after all, the basic
reason why NetUI page flows are created is to provide a simpler manner of
easily maintainable flows in an application . If we can do so in struts by
modularizing the config files (and probably putting those broken files in
their respective folders -- hope I am not mistaken here), then doesn't this
negate the need of java page flows in NetUI?
	Hey Rich, did u put the sample codes as u said u would do for the
DynaActionFormBeans and customized validation messages in Beehive? It'd be
great if u posted them :)

Thanks a lot
-- Vaibhav

-----Original Message-----
From: Rich Feit [] 
Sent: Friday, December 02, 2005 10:48 PM
To: Beehive Users
Subject: Re: Doubts on Apache Beehive.

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
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

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