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: domain of richfeit@gmail.com designates
 64.233.162.204 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=JBWg9rg+xnifXTMtJ+2oOxiFk8IdduiqjyTP6L0KLWf+Ji1YGnodH2lspl4iVmIFUmQ7fYueJdvUwgYGa1bJgDS8rFKD334WeSu3BhN0Qu1jye4OjPsRUW0iEbO11LScbjqxJwdT93rYJRXULf1tmBwQp6+xcZTaBGCReFV/dSI=
Message-ID: <4391C117.1080308@gmail.com>
Date: Sat, 03 Dec 2005 09:00:23 -0700
From: Rich Feit <richfeit@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: Beehive Users <user@beehive.apache.org>
Subject: Re: Doubts on Apache Beehive.
References: <649724FF840E9941841244753DD3E9650BE98A@exchange.sigma.com>
In-Reply-To: <649724FF840E9941841244753DD3E9650BE98A@exchange.sigma.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

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