OK, finally got this in a state where you can see it without checking
out our dev tree. Just do this:
- Download and extract netui-samples.zip from
http://people.apache.org/~rich/ .
- Update netui-samples/build.properties to point to your Beehive
home directory.
- Run 'ant build war' in the netui-samples directory.
- Deploy netui-samples.war to the server.
The two relevant samples are under Advanced if you hit the root of the
webapp: "Custom Validator" and "DynaForms" (web/advanced/customValidator
and web/advanced/dynaforms, respectively).
As to the dev2dev link, that refers to Beehive's predecessor: the BEA
WebLogic Workshop 8.1 runtime. So yes, it's obsolete. :)
And... regarding your earlier questions about modularizing Struts config
and the value of NetUI:
a) Here's an article on Struts Modules (there are many others if you
do a search):
http://www.onjava.com/pub/a/onjava/2002/10/30/jakarta.html?page=2
b) Centralization is one benefit of NetUI, but it goes beyond
modularization of the *config*. When you write a page flow controller,
you are encapsulating config (in annotations) *and* action logic,
exception handler logic, and state related to the controller.
There are many other benefits of NetUI, though; see
http://beehive.apache.org/docs/1.0/netui/overview.html for starters.
One additional comment I wanted to make about NetUI "vs" Struts is that
they're not mutually exclusive. Beyond the fact that page flows
generate Struts modules, NetUI integrates well with raw Struts -- you
don't have to choose one or the other.
HTH,
Rich
Beohar, Vaibhav wrote:
> 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:[EMAIL PROTECTED]
>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:[EMAIL PROTECTED]
>>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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
