Re: Project architecture
Re: Project architecture
- Subject: Re: Project architecture
- From: "Webobjects Developer" <email@hidden>
- Date: Thu, 29 Mar 2007 10:48:49 -0700
Thanks for the useful reply (and to the others who have pointed out
the value of DirectActions).
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.
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?
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?
On 3/29/07, Guido Neitzer <email@hidden> wrote:
Hi,
Perhaps you are mis-interpreting something in WebObjects: a
WOComponent might be a page. Or might be a snippet of a page. Or
might be a wrapper around something. Or might be something completely
different. But it has nothing to do with the actual URL to view
exactly one page.
We have designers here that actually use WebObjects Builder to build
components for websites, but that is a more special case. 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. As a page is normally build by a couple of
components (like wrapper, header, navigation, content, special
content, ads, footer, legal stuff, search box ...) it is not
practical to have a designer working on the components itself.
For bookmarkable URLs you need to use DirectActions, which means you
don't have a session - be careful because lots of the dynamic
elements create sessions when they are used on a page. Perhaps get a
book, that explains the use of DirectActions and how to transfer a
component action based app to a stateless one [1].
And the rest is not really "project organization", it is more on how
you build the pages itself. Use direct actions where possible (where
you don't have a state like a logged in user or so), perhaps use
direct actions even if you have a logged in user, but use a session
when he logs in to maintain the state. Build code that handles users
coming back to one of those direct action links with an expired or no
session. Put the session id in a cookie to have clean direct action
URLs without the wosid parameter.
cug
[1] old, but still a good book to read in my opinion, if you can
transfer to the modern tools:
<http://www.amazon.com/WebObjects-Web-Application-Construction-Kit/dp/
0672320746>
On 29.03.2007, at 11:03, Webobjects Developer wrote:
> I'm a relative newcomer to WebObjects, but I've built a few
> applications and feel like I have a good handle on the technology. I'm
> thinking about using WebObjects for my next online project.
>
> My question is about project architecture. I envision the following
> major components:
>
> - The backend database
> - The administrative web site
> - The [non-secure] user web site
> - The [secure] store web site
>
> My goals are to:
>
> - Hire a non-technical web designer for the user web site and store
> web site
> - Use off the shelf tools like Dreamweaver or Go Live for web design
> - Include some dynamic content in user web site
> - Provide bookmarkable, non-cryptic links to user web site
>
> For instance, it seems unreasonable for my web designers to deal with
> the WO component .html or .wod files of the WO project.
>
> Also, using WO components for the user web site pages makes it harder
> to provide bookmarkable links for the pages on the user web site that
> have dynamic content.
>
> But if not WO components for the pages, then what?
>
> What are the suggested WebObjects techniques for organizing a project
> to meet the goals above?
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> s.net
>
> 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