Re: Project architecture
Re: Project architecture
- Subject: Re: Project architecture
- From: Chuck Hill <email@hidden>
- Date: Thu, 29 Mar 2007 15:25:41 -0700
On Mar 29, 2007, at 1:02 PM, Webobjects Developer wrote:
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 am not sure you are understanding the architecture here. The
browser sends the request to Apache, Apache decides it is for WO,
sends it to mod_webObjects which consults wotaskd to select the
appropriate instance and sends the request to a WO application. SSI
only works on static pages and is an Apache, not a WO, technology.
You can't use SSI in dynamic pages (well, not sure about that in
Apache 2).
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.
Most. :-)
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.
I think the problem might be your perception of WO. WO is meant to
build web _applications_ not web _sites_. Generally, the web
designer does not just decide to add a page. A page gets added, and
linked to other pages, because there is a business need. Often that
requires code changes, yes. If you are just building a site, then
what you want is to use WO to build a CMS application like Guido
described. See http://www.gvcsitemaker.com for another example).
The designer is then just a user of the WO application.
Chuck
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
--
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