Re: Project architecture
Re: Project architecture
- Subject: Re: Project architecture
- From: "Webobjects Developer" <email@hidden>
- Date: Thu, 29 Mar 2007 11:44:00 -0700
WebObjects applications tend to be bigger ones. If your needs aren't
high, you probably go better with PHP or whatever other scripting
language. But then your designer may even break your code when he
does changes - so, it's up to you.
I've spent a considerable amount of time evaluating WO vs. other
solutions such as PHP or other Java based solutions; but, in the end,
I think the advantages of server administration, EO, and WO
scalability make it a good choice, even for small/new projects.
I was hoping that others had already solved the problem of integrating
web designers into the workflow without going all the way to a full
blown CMS, which sounds like a great idea for larger projects like
yours.
Conceptually, this problem seems straightforward to solve. It could
function similarly to how both WO and PHP function already: the web
server grabs a page from the site. It scans through to see if there is
anything that needs to be handled by WO and then it passes it off to
the WO handlers that supply content that gets inserted into the web
page and served to the user.
I guess the trick is to place all of the .html files in a common
directory that can be edited by the web designer. Then minimize the
use of the <webobjects> markup so that the web designer doesn't have
to learn much.
The problem with this approach is that new pages necessitate new WO
components, right? And is WO capable of grabbing the .html files from
a location outside the application?
On 3/29/07, Guido Neitzer <email@hidden> wrote:
On 29.03.2007, at 11:41, Mac Developer wrote:
> The part that scares me (for which I'm still looking for a solution):
>
>> ... Normally
>> our workflow is to get working HTML mockups for every page in the
>> application and a programmer transfers that to the actual components
>> and the application. ...
>
> This seems like a maintenance headache. If the web designer decides to
> make a minor change to the website, it is up to a [costly] programmer
> to take the change and put it into the application.
You have to be careful with your judgement about maintenance.
1. Content in such systems is normally stored in the database. So,
every "standard" change to a page, which is normally a nightmare for
permissions, uploading and so on, can be handled by an admin app.
2. If real minor changes in design are costly, the design is not made
for such a site. Normally you can do a lot of things in CSS.
WebObjects applications tend to be bigger ones. If your needs aren't
high, you probably go better with PHP or whatever other scripting
language. But then your designer may even break your code when he
does changes - so, it's up to you.
What I'm currently developing in my spare time is a system that is a
completely dynamic CMS. It can handle multiple domains, sites,
wrappers, pages, custom content and so on. More or less EVERY content
is stored in the database. For CSS and images, I create a database
entry for information about the file and store the file on the file
server.
A designer can go to an admin application and create a new site, add
CSS files, images, and so on to the site. Adding pages is done in the
admin application too - if you just want to add more or less plain
HTML pages, there is a "CustomHTMLComponent" you can add to a page
object and this is rendered as the content. Every component can
request additional styles to be included by the wrapper, the
navigation is build dynamically with unordered lists of the active
pages, the design happens in CSS and in ordering the elements on the
wrapper and the pages itself.
A real drawback of this is, that you need a more powerful database if
the load increases. But one of our production apps is build similarly
and this has handled more than 100k page views per day with web
server, application server and database all on a single machine (Dual
G4 867, 2GB RAM).
> I've heard this suggestion (of web designer -> programmer -> online
> workflow) from a few people. But surely there must be a better way!
> Isn't this a bottleneck?
Actually, no. Not here. If your designer is not too technically
inexperienced you can have him working on the components afterwards.
> Also, how would you pass this application on to a customer who might
> want to make minor changes to the website without returning to the
> developer?
If you pass a WebObjects application to a customer who wants to make
changes, he has to have a certain amount of knowledge. If he has not
- make a service contract.
As I said before: average WebObjects applications tend to be bigger
and more complex than the average PHP solutions. It will also be hard
for a customer to find a deployment environment and so on. If you are
really scared of that, use a different tool. Because you will not be
happy with WebObjects.
cug
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden