Jon Stevens wrote:
> This essay is of particular interest to these lists because it explains a
> lot of the reasons why using ECS to build websites in this day and age, is a
> bad idea.
but, you see, i'm not interested in building websites - i'm interested in
delivering applications over TCP/IP networks.
i've thought about it since the last time that this thread came up and maybe
that's what that navy guy was talking about. websites are cool. lots of clever
people have spent lots of time creating lots of neat toys for building
websites. but you can also use those toys to play another game - and that's
writing applications that run from a browser.
MS are into this game - but there stuff is IMHO (at the moment) deficient.
setting asside the fact that you're tied to one market sector (100% MS
companies - not 90%, not 95% but microsoft clients, servers, webbrowsers and
database), their technology is still a little shaky.
if you're in a team working on a website, i guess (from YMTD) that you'll have
as many web-designers as java engineers. in application teams, good web
designers are at a premium. i suspect one reason why jsp's have a syntax which
is aimed at coders is because in many cases most pages are coded (i guess that
this probably a more accurate term than 'designed') by the people who write the
underlying java - or by junior developers who can't be trusted to write deeper
stuff. quite probably (if you're writing applications) the actual look and feel
design will be deligated to bespoke teams - either consultants on the client
site, or actually working for the client.
> Yes, ECS still has a purpose. In fact, it is still used throughout the core
> of Turbine as a way to deal with DOM-Style elements, but typing out all of
> your HTML as ECS objects really isn't the right way to do things anymore.
> Time to move on.
i think that where i disagree with your line of arguement is the "typing out
all of your html" implies "using ECS is wrong" bit. certainly "typing out all
your html" is plain wrong - and in as much as ecs encourages people to do this,
it's a bad thing. it's an interesting question - and old - whether you avoid a
tool simply because it can be used in a bad way...
*but* i'd say that there are some times when "typing out some html" from your
java is justified - and ecs should be there to make this easier, more readible
(IMHO code readability is one area where ecs could be improved) and more
robust. how many foriegn key relationships are there in a large database
application? how many small volume tables which are used to normalize the
database? all these need to be fetched as select options onto data-entry forms.
how many tables of results? how many list-style reports? i think that writing
this common functionality into libraries which can be reused is actually quite
a good idea. do web designers really want to spend all day creating select
buttons? when it comes to applications, they should be designing the global
look and feel, not bothering with details which have more to do with database
design. i agree with you 100% that in a team, people should do what they're
good at. in the same way that java engineers shouldn't design web sites, so web
designers shouldn't need to be database experts. in addition, there are going
to be times when it's actually better design to hide some html in java classes
so that the implementation can be changed without breaking loads of pages.
PS. jon - before you ask ;-), interesting article
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
