Struts Development can be very simple and productive if you design a POJO based view layer.
I designed a POJO based View layer, the following are the core members of the layer, Page, -- Top panel Tab, -- differentiate active tab and inactive tabs and fields on each tab Button, -- you know Field, -- you know Summay, -- display free form data ValueList,-- display tabular data SearchCriteria -- display the search criteria for valuelist I only have one set of JSP files and they can display as many domain objects as you want. And the number of actions is less then the number of pages. For example, the fields to be displayed on the summary area of the page is defined in a property file, so the page can pick up the value of the properties of the domain objects and display them automatically. The domain object can be assoicated to other domain objects or composite key and the configuration of the property is JSTL-like pageName.summary.fields=myObject.itsCompositeKey.id, myObject.itsChild.someProperty,myObject.anotherProperty in the Resources Bundle file. The input fields are also automatically generated. When Editting, instead of display value, it creates 3 fields on the HTML form, <input name=myObject.itsCompositeKey.id <http://myObject.itsCompositeKey.id> > <input name=myObject.itsChild.someProperty> <input name=myObject.anotherProperty> By contract, the domain objects need to be Java Beans. So it is a relief from struggling with JSF, JSPs, JSTLs and Actions, everything is just POJO. Only one Action is used to get the ValueLists of million types of domain objects. The development is very productive considering it eliminates so many tasks. On 11/10/05, Dave Newton <[EMAIL PROTECTED]> wrote: > > Michael Jouravlev wrote: > > >On 11/9/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > wrote: > > > > > >>Anyway, now we're moving to a new J2EE development environment and > trying > >>to decide how to build apps going forward Struts is the logical choice > >>because we know it. However, one of the big issues we have with Struts > >>right now is that it still involves a lot of things to be done "by > hand". I > >>don't mind but management keeps coming back at us with "how come the > .NET > >>group can crank out the webapps so much faster? Why do you have to build > >>all these common components? Why does it take so long? blah, blah, blah" > >> > >> > > > >Why don't you (your team) just switch to .NET? This is not a sarcasm. > > > > > Are you allowed to say that? ;) > > Michael has a good point: if you're changing infrastructures anyway, and > you already have an in-house .NET knowledge base, what is the compelling > reason to stay with J2EE? > > An why _does_ it take "so long" for your J2EE team to build > applications? That's a legitimate question that you'll have to answer. I > have no ability to purchase tools at this time, but by spending a small > amount of time with a decent language (I use Ruby and/or Lisp) you can > often automate large chunks of previously hand-driven stuff. For > example, I run a ruby script to add an action to a webapp: it adds the > action mapping to the struts config, creates some default things in my > app resources, creates a JSP tile chunk and creates a tile definition, > etc. There's still stuff to do, but not as much as before, and it keeps > you from forgetting Really Important Stuff. > > Believe me, I have little love for the .NET development experience > (although C# is pretty nice as "normal" languages go) but... > > Dave > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Yujun Liang [EMAIL PROTECTED]
