Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Project architecture

Another aspect of site design that you seem to be missing is that a well designed site will isolate the static and dynamic parts of the site.

Take Apple's own web site as an example.  Browsing around you will quickly notice that the entire site is not wrapped in WebObjects.  The home page and many other pages are simple static pages like any other site.  But, clicking on the "Store" tab at the top will immediately redirect the user to the Apple Store WebObjects application which then offers up a set of publicly accessible dynamic pages build using WOComponents.  It's not until you wish to check out are you asked to log in with your account credentials.

The same thing holds true if a user clicks the ".Mac" tab from either the static site content or from within the Apple Store application.  This will then direct the user to a completely separate and independent WebObjects application to generate all the cool .Mac stuff like the new Mail application within .Mac.

You will also notice other "non-WebObjects," but still dynamic pages developed in other web application technologies.

It's all a matter of choosing the "right tool" for the job at hand.  It really makes no sense to force fit any technology into tasks it's not well suited to service.

Also for those areas that cross over between "designer" HTML and "programmer" HTML (contrived terms warning) WebObjects offers nice component architecture to help deal with that.  What we do is work with the web designers to think in terms of "partial" HTML content design.  Experienced layout designers are used to dealing with a form of "placeholder" content.  Most are fine with looking at a rectangular area of "something will go here" such as the case when photographers are out on a shoot and a layout manager simply inserts a "picture placeholder" into their design know something of what will be there but not having the final resources.

Also don't forget about the power that comes though CSS.  If a good consistent CSS style sheet is provided to both the designer and programmer there will an inherent compatibility between the HTML produced by the designer and by the programmer.  When all this is combined with a well thought out "wrapper" design within you WebObjects application many of these concerns can be reduced to a minimum.

On Mar 29, 2007, at 1:48 PM, Webobjects Developer wrote:

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:

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

--
Robert Walker


 

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/email@hidden

This email sent to email@hidden
References: 
 >Project architecture (From: "Webobjects Developer" <email@hidden>)
 >Re: Project architecture (From: Guido Neitzer <email@hidden>)
 >Re: Project architecture (From: "Webobjects Developer" <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.