As I see it, there are three types of pages:
- static,
- non-persistent dynamic,
- persistent dynamic.
I actually see this list slightly different:
- static pages (no dynamic content)
- stateless dynamic pages (requiring no session management but still contain
dynamic content)
- stateful dynamic pages (requiring a session to track user's action, but
not to protect content)
- stateful secure pages (requiring a session and a login and likely SSL)
I haven't worked much with direct actions, but if a web designer adds
a non-persistent dynamic page to the site, do I need another WO
component to handle it? Or can WO just serve up all pages in a
particular directory?
If it were me I wouldn't use WebObjects in this manner. In my opinion it's
not really the same as a basic page pre-parser like PHP. WebObjects shines
when it has direct access to resources such as the database content, static
HTML templates, CSS, JavaScript and anything else that makes up the dynamic
content. And to have these resources available on the Application Server
(whether that is, or is not, the same box as your Web Server).
I think about it this way. Most web servers tend to provide content for
multiple domains from a single server box. PHP also tends to follow this
same pattern given it is so directly connected to the web server itself.
WebObjects is different. You tend to think about how many server boxes will
be used to serve up the dynamic content from the resources and database (or
database cluster). There is really no direct connection to the request
hitting the web server. The requests are forwarded by the HTTP Adaptor to
the Application server and the web server immediately goes on with it's
business until it hears back from the HTTP Adaptor. The adaptor is
responsible for redirecting the next request to the proper application
server and instance.
So WebObjects is a larger solution in that it manages a cluster of servers
including load balancing solutions. To do this with PHP requires additional
tools to manage the clustering. This also goes for other scripting
technologies like Ruby on Rails.
Sorry that was a bit of a complicated way to say that PHP templates tend to
live in the same "realm" as the web server, this is not the case with
templates in WebObjects, and for good reason.
"A hammer is great for driving nails, but isn't so great at driving screws."
On Mar 29, 2007, at 2:53 PM, Webobjects Developer wrote:
You have good advice. The question is how to implement/architect it?
As I see it, there are three types of pages:
- static,
- non-persistent dynamic,
- persistent dynamic.
But from a web designer perspective, they will be designing all of the
pages to look and feel the same. They will share structure and css.
The web designer can design using placeholders, of course. But my
question is more how to make it easy to take what the web designer has
done and integrate it into the WO application.
What WO project structure do I use to serve static, non-persistent
dynamic, and persistent dynamic pages from a single directory? The
default projects have the .html files inside the WO component
directories... i.e. distributed into multiple directories.
I haven't worked much with direct actions, but if a web designer adds
a non-persistent dynamic page to the site, do I need another WO
component to handle it? Or can WO just serve up all pages in a
particular directory?
On 3/29/07, Robert Walker <email@hidden> wrote:
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:
<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
--
Robert Walker
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
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