It's a port from a combination of S1.3, actions, and servlets, so it's been
a big jump.
There aren't that many hurdles once you're familiar with the S2 way of doing
things. S2 has made life a lot easier, the UI codebase a lot smaller, and is
generally a good move.
----- Original Message -----
From: "Martin Gainty" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <user@struts.apache.org>
Sent: Sunday, April 06, 2008 4:54 AM
Subject: Re: [OT] What do you code today?
Al-
Any pointers you can share on porting ?
M-
----- Original Message -----
From: "Al Sutton" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <user@struts.apache.org>
Sent: Saturday, April 05, 2008 2:51 AM
Subject: Re: [OT] What do you code today?
http://www.enterprise-password-safe.com/
At the moment the code is under a major overhaul to use S2.1 (yes, 2.1)
and
add some new features, hence my big interest in 2.1 :).
Al.
----- Original Message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <user@struts.apache.org>
Sent: Friday, April 04, 2008 12:14 PM
Subject: [OT] What do you code today?
> While outward facing web application get the most publicity, I know
> that most of us are heads-down on internally-facing applications
> designed for fellow employees to use over the corporate intranet.
>
> I'm trying to put together a list of the typical types of applications
> that enterprise developer write in real life. For example, my last
> project involved a system to track drafting, granting, monitoring, and
> enforcing water permits administered by a government agency. We would
> create an initial record for a permit, and then add child records to
> track progress through the workflow, and also update the master record
> along the way. For management, a key item here is a tracking report,
> which we exported to Word (using a third-party tool) for better
> formatting. For engineers, a key item was a flexible search system to
> quickly find a master or child record. Other interesting features are
> workflows where one task leads to another. When we completed one task
> (child record), the next is often implied, and so we had a workflow
> that would default the next task to work on when a current task was
> closed. Another interesting requirement was that sometimes master
> items were merged under another uber-master-item, becoming, in effect,
> child items themselves. In most cases, the application simply exposed
> business models that we designed into the database, so the application
> has little business logic of its own. Most of the workflows were
> designed to find, list, edit, or view one database entity or the
> other.
>
> So, if anyone else is up for sharing, I'd be interested in hearing
> what sort of things other people are doing these days. (If your not
> comfortable posting the list, feel free to mail me direct.)
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]