Mailing-List: contact user-help@beehive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Beehive Users" <user@beehive.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <649724FF840E9941841244753DD3E9650BE98E@exchange.sigma.com>
From: "Beohar, Vaibhav" <VaibhavB@sigmasoft.biz>
To: 'Beehive Users' <user@beehive.apache.org>
Subject: RE: Doubts on Apache Beehive.
Date: Mon, 5 Dec 2005 14:41:27 +0530 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

 Hi Rich, 
	Yeah the suspense sure is killing me :) I don't think I have access
to the tree that u are talking about. I went to beehive.apache.org and spent
a good amount of time figuring out the directory structure you mentioned but
couldn't find it. 
	Anyways, If you are posting it somewhere else please do inform the
group as well :) will have a look at the code.
You know what, I have had a look at this link of weblogic workshop FAQ and
it says beehive doesn't have support for DynaActionForms... I mean, am I
mistaken here or is this link obsolete? Have a look at it here --
http://dev2dev.bea.com/pub/a/2004/05/pgflow_netui_faq.html#pgflow6
	
	And a general question to the group -- Does anyone have a
compendium/web-link on the following topics on Beehive --
	1) When not to use apache beehive?
	2) What are the limitations of apache beehive?
	3) Learning curve 

Regards,
Vaibhav 
	
	
-----Original Message-----
From: Rich Feit [mailto:richfeit@gmail.com] 
Sent: Saturday, December 03, 2005 9:30 PM
To: Beehive Users
Subject: Re: Doubts on Apache Beehive.

Hi Vaibhav,

I did check in a sample for DynaActionForms last night -- it's in the tree
at samples/netui-samples/advanced/dynaforms.  I didn't get a chance to put
the custom-validation example into the samples yet, but there is an example
of that in the tree at netui/test/webapps/drt/web/validation/custom.  I
should have that one in the samples by Monday (and if you don't have access
to the tree currently I'll be able to post them somewhere else).

I've definitely got more responses, but unfortunately I'm on my way out of
town until tomorrow night -- will reply then.  Hope the suspense isn't
killing you.  :)

Rich

Beohar, Vaibhav wrote:

> 
>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 [mailto:richfeit@gmail.com]
>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
>>    
>>
>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.Controller(
>        messageBundles={
>           
>@Jpf.MessageBundle(bundlePath="messages.defaultMessages"),    // this is
>the "default" message bundle -- not named
>            @Jpf.MessageBundle(bundlePath="messages.another",
>bundleName="another")
>        }
>    )
>
>These point to /messages/defaultMessages.properties and 
>/messages/another.properties, 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.
>
>Rich
>
>  
>
>>Thanks,
>>Vaibhav
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 
>>
>>    
>>
>
>  
>