Re: Project architecture
Re: Project architecture
- Subject: Re: Project architecture
- From: "Webobjects Developer" <email@hidden>
- Date: Thu, 29 Mar 2007 13:02:09 -0700
You could use SSI to include dynamic parts by calling direct actions.
Good idea. I'll look into this. Perhaps WO can even do it directly by
intercepting the URL before it gets passed to the direct action...
I don't think technology is going to do much to compensate for a
designer who does not want to or can't learn new things. If they
can't "get" <webobject name="FirstName"/> what you need is a new
designer.
In my experience with HTML (and my limited WebObjects experience),
things rarely come down to something so simple. I wouldn't want to get
rid of good web designers because they didn't want to learn the
intricacies of WO.
However, I don't think template substitution is the big problem
anyway. Most web designers would be able to handle that.
I think the problem is how to detach the programmer from the web
designer. So if the web designer adds a new page that utilitizes
existing WO components, that a new WO component to represent the new
page itself doesn't have to be created by a programmer. But I guess
that's where the SSI (or similar) solution might work.
On 3/29/07, Chuck Hill <email@hidden> wrote:
On Mar 29, 2007, at 11:44 AM, Webobjects Developer wrote:
>> 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.
You could use SSI to include dynamic parts by calling direct actions.
> 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.
I don't think technology is going to do much to compensate for a
designer who does not want to or can't learn new things. If they
can't "get" <webobject name="FirstName"/> what you need is a new
designer.
> 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?
Yes, see http://en.wikibooks.org/wiki/Programming:WebObjects/
Web_Applications/Development/Custom_Templates
Chuck
> 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:
>> email@hidden
>>
>> 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:
> 40global-village.net
>
> This email sent to email@hidden
>
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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