I'm working on an external and internal facing portal application using BEA
AquaLogic UI (ALUI), plugging some holes with S2 based portlets, mainly
dealing with moving our customers from DB based auth to LDAP through the
portal.

With ALUI you can use either JSR-168 portlets or plain old web apps so we
have taken the plain old web app course and have not used the portlet
plugin. One of my co-workers has created some portlets using the JSF plugin
with good results. 

These portlets are mainly customer self service for our many service
offerings and oriented towards customer support on the internal facing
stuff.

Overall we love the framework, much better than S1!

Regards,
Randy Burgess
Sr. Web Applications Developer
Nuvox Communications



> From: Ted Husted <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <user@struts.apache.org>
> Date: Fri, 4 Apr 2008 07:14:33 -0400
> To: Struts Users Mailing List <user@struts.apache.org>
> 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]
> 



This email and any attachments ("Message") may contain legally privileged 
and/or confidential information.  If you are not the addressee, or if this 
Message has been addressed to you in error, you are not authorized to read, 
copy, or distribute it, and we ask that you please delete it (including all 
copies) and notify the sender by return email.  Delivery of this Message to any 
person other than the intended recipient(s) shall not be deemed a waiver of 
confidentiality and/or a privilege.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to