Andreas,
Thanks for the ideas - I see your point about the dangers of a proprietary solution.
When it comes to changing the site in such a way that new actions are required (more a
framework change than a content change), this really has to go through a test and
user-acceptance process, hence access would be required to the development servers,
whereas static content (i.e. news updates) is a far less serious change which I want
to happen quickly and easily by piviledged users (i.e. via an online wizard).
I've made some progress to writing a tiles definition factory which uses a database -
it has been (so far) easier than I expected. I'm going to give it a go and see if it
works. One further issue I have to contend with is that the production servers are 11
completely independent machines.
Paul
------------------------------------------------------------
Global Equity Derivatives Technology
Deutsche Bank [/]
Office +44 (0)20 754 55458
Mobile +44 (0)7736 299483
Fax +44 (0)20 7547 2752
------------------------------------------------------------
"Dr. Andreas
Kr�ger" To: Struts Users Mailing List
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED] cc:
-ratio.com> Subject: Re: Dynamic assignment of
tiles
03/12/2003 10:23
Please respond to
"Struts Users
Mailing List"
Paul-J Woodward anticipates
> the need to store the contents of uploaded pages in a database as a blob,
"War story" / food for thought:
Almost ten years ago and totally unrelated to Struts or even Java, I did
something similar. At that time, I had very good success with a home brew
object oriented concept on top of a relational database.
I thought of my individual database row as an "object". There would be a
relationship to a "class". If I wanted to do anything particular with the
object, I would think of it as, "I want to call a method". Given the class
and the name of the method I wanted to call, a database lookup would tell me
which particular implementation would do the trick.
In this way, I had, in fact, implemented object orientation. The
architecture would easily accommodate various implementations for special
ways of performing common tasks. In my own (biased) opinion, the net result
was an stable, flexible and successful architecture. The customer loved it,
too (the stability in particular). The major drawback was that, for a
couple of years or so, I was the only one who dared to touch the code.
In this age of Java, of course, you could simply use EJBs. I recommend you
evaluate whether they fit your needs (I you haven't done that already).
Regards,
Andreas
Dr. Andreas Kr�ger, [EMAIL PROTECTED]
DV-RATIO Nordwest GmbH, Tel.: +49 211 577 996-0, Fax: +49 211 559 1617
Leostra�e 31, 40545 D�sseldorf, Germany
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
