I certainly understand your concerns
and they are valid. WO is already a very expressive framework and you have
a work process that simply does what you need. You are agile and get things
accomplished. You don't have a need to try something new. I also understand
that if you were to try this there would be major growing pains because
your workflow currently uses a raw .html file with little webobjects tags
you ask the UI people to ignore.
I had the same concerns a few years
ago but threw concern to the wind for non-serious projects so I could give
it the benefit of the doubt. For me it was enough to see some smart discussions
on their equivalent of WOCommunity and see killer apps come to market like
"DabbleDB." I took the leap of faith and can now visualize it
better. To be honest my very first impression was that this was a "cop-out"
design decision. I really thought they did things this way to obviate the
need of creating a template system. It wasn't until really trying it out
that I could see how wrong that assumption was. This is no simple high
school project framework, it's a well laid out approach.
You are right Simon, if the HTML being
output does not have enough syntactic sugar as in http://www.csszengarden.com/
then the UI people will be nagging the programmers. It will cause issues.
But fairly quickly I would think programmers will learn what is necessary
and overall flow will be improved. Usually it is not "id" tags
but classes and nested spans / div tags that are necessary.
The following two posts are pretty succinct
and illustrate this novel approach eloquently.
The second post is particularly interesting
as it shows how Ajax is very sensibly added to your application. He says
not but the extra _expression_ in the web framework did it for him. Just
like EOF creates SQL for you or even Mike's WO Ajax framework can automatically
directly. Blur your eyes and try to see the difference using a new Webobject
tag with various bindings for an AjaxObserveField versus this method of
accomplishing the same goal. It is eye opening.
Simon <email@hidden> wrote on 09/29/2011
> From: Simon <email@hidden> > To: Chuck Hill <email@hidden> > Cc: email@hidden, WebObjects Mailing
> email@hidden> > Date: 09/29/2011 03:28 AM > Subject: Re: Finding WO people for startups (cult
of the dead) >
> >> renderContentOn: html
> >> html table: [
> >> html
> >> tableRow: [
> >> html tableData: [html text: 'Table entry']];
> >> tableRow: [
> >> html tableData: [html text: 'Table entry']]].
> >> Look foreign? Perhaps but it's worth getting your feet wet
> kicking these ideas around. I've seen many things and this is the
> first set of tools and processes that make me feel good. Like it is
> equivalent and perhaps better than WO. It's brain dead easy to
> install and there are a number of tutorials out there.
> > OK, I see what you are talking about now. I am not sure
> is a win for me. I have this designer that I often work with
> is able to take an Eclipse project and edit the .HTML files to make
> design changes. He does not touch the WOD or the Java. This
> been working pretty well for us. Switching to Seaside would
> that we would have to take the initial designs, convert them into
> code, and have the developers maintain them through the inevitable
> changes. I'd have to see how much time the rest of it would
> totally agree. this is not a plus for us either. our UI people play
> with html (we don't do wod's, 100% inline bindings), and our java
> people play with Java.
> the thought that our java team would have the UI team on their backs
> all day saying "er, can you change that <table>, <tr>
and <td> mess
> you're pumping out for a list please (like i told you last time)"
> fills me with fear!
> even if you keep your UI people to tidy up with css, surely they are
> going to be nagging java engineers to get the correct id's and classes
> pegged to the html the java code is pumping out ? it seems this is
> only a benefit if your java people actually look after the whole UI
> piece as well - and i've yet to find a java engineer that has style.
> no offence intended :-)
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