Maybe this will help:
When you ask WO to begin generating a page (component) with something
like:
WOComponent page = pageWithName("MyPage");
the framework will locate the class MyPage and create an instance of
MyPage for you. The next thing that happens is the framework will
attempt to locate a component (HTML, WOD, API) by name "MyPage.wo."
After this the Request Response loop continues by calling
takeValuesFromRequest, invokeAction, and appendToResponse (simplified
for demonstration).
The framework locates these "resources" using the
WOApplication.resourceManager(). This will look inside your
application wrapper. MyApplication.woa. This exists somewhere on
your Application server.
When the designer adds a new page, what process takes place after
that? Does a programmer need to be involved (assuming that the new
page is dynamic, but only uses existing WO components)? Does the
application need to be rebuilt and deployed again?
The simple answer is YES.
The more complex answer, as others have pointed out, is that
WebObjects is a full fledged programming environment in which you can
accomplish practically anything you put your mind to.
Research what other have done for CMS solutions. This may be exactly
what you're looking for. Chuck Hill's comes to the forefront of my
mind.
On Mar 29, 2007, at 5:28 PM, Webobjects Developer wrote:
You're completely correct that most (all?) publishing systems have
this problem. And I think you (and others) are right that inserting
special placeholder HTML is not a big problem. But as I asked to
another responder:
When the designer adds a new page, what process takes place after
that? Does a programmer need to be involved (assuming that the new
page is dynamic, but only uses existing WO components)? Does the
application need to be rebuilt and deployed again?
Also, I think you're right on when talking about the whole "HTML"
thing. Unfortunately, that's the way things are right now. So finding
tools to deal with it is the problem at hand.
CSS is nice too, but ultimately doesn't help for structural layout (at
least without also changing the underlying HTML "data"). Admittedly,
layout may change less frequently than text on the page. But it still
does change.
On 3/29/07, Robert Walker <[EMAIL PROTECTED]> wrote:
I think it's also noteworthy to mention that WO is not unique in
this at
all. You would have exactly the same issues with anything based
on J2EE.
JSPs are not dissimilar to WO Templates. Even some scripting
solutions like
Ruby on Rails are not immune from this. You're still going to have
programmer specific custom tags within the UI that a pure web
designer will
have to work around.
I personally think the real problem is not that HTML is for
designers, but
that designers are having to deal with HTML "code." If the web
was build by
designers instead of programmers then designers would not ever see
the HTML
code.
Designers working in Adobe InDesign never see, or care anything
about, how
InDesign keeps track of formatting text and graphics on a page,
nor should
they. On the contrary a UI programmer cares very much about how
the system
organizes windows and views within those windows. They need to know
specifically how to interact with those objects from within their
code.
So this is not IMHO a failure in any way of WebObjects or any other
solution, it's a failure of the basic design of the Web in
general. So we
do the best we can by building good communication and cross
training between
coders and designer to work around this fundamental flaw.
CSS is helping, but it's still to much for the programmer and not
enough for
the designer, this is getting better all the time as the design tools
improve. A Web build by the likes of Adobe would have made it a much
difference place than it is today. Designer wouldn't be dealing
with code
and there would be a much more distinct divide between web "pages"
and web
"applications."
On Mar 29, 2007, at 4:08 PM, Webobjects Developer wrote:
Using WO, how does one separate the web designer from the programmer?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/
webobjects.dev%40gmail.com
This email sent to [EMAIL PROTECTED]
--
Robert Walker
[EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
