As I recall the transformations were cached; performance was not an
issue (also, this was a low-volume intranet application).
Pilgrim, Peter wrote:
-----Original Message-----
From: Dakota Jack [mailto:[EMAIL PROTECTED]
Sent: 16 November 2004 17:46
To: Struts Users Mailing List
Subject: Re: talking about paradigms
Bill,
Sounds like you don't need what XSLT provides. The important thing, I
think, is to make sure that the framework leaves that option open for
those that want it and does not require that option to those who do
not want it. I am not privy to the details of your application, of
course, but adding code to the controller to assist in the
presentation seems to me to indicate a serious design flaw. That
simply is not the business of the control layer, if you are using the
control layer in an MVC pattern. Part of your bad experience with
XSLT sounds like it is not related to the view issues but to some
confusion in the architecture of the application? Not knowing much
about the details, this is probably a harsh assessment, but it is what
I would intuitively expect to find. My head keeps saying "What the
heck is the controller doing generating XML?". The controller should
be deciding what to do about user input given whatever strategy the
application has adopted.
Jack
On Tue, 16 Nov 2004 10:55:52 -0500, Bill Siggelkow
<[EMAIL PROTECTED]> wrote:
Jack,
What I found was that alot of Java code to generate XML
(using DOM API)
had to be added in the controller layer to facilitate the view; for
example, an odd/even indicator was added just to facilitate
striping on
the generated HTML table; to me, this seems downright
overkill for some
feature that is purely presentation (granted, the
developers could have
avoided this through better use of XSLT).
Personally, I've never warmed to the idea of using the
XML/XSLT approach
when the data is already in the form of a Java object; it just seems
like an extra step that doesn't buy me a whole lot.
-Bill Siggelkow
I have never come across anyone in a face-to-face who uses
the XML/XSLT approach at least with Struts. I met a straight-up
Cocoon fantastic a few years ago, but by then he was moving
away from XSLT to proprietary web application framework on
some app server.
This biggest problem of the XML is the transformation phase,
and it sounds like that the original tabular XML was not
augmented with attributes to say this is hint "render
this row in green" and now "render that next row with
white background". Then an XSLT can be written to easily
transform things around (or not as the case may be).
I think XML/XSLT pipeline is useful for static stuff that
mostly does not change frequently. How did you find the
XSLT transformation performance on your project?
Did you cache the XSLT results somewhere?
Dakota Jack wrote:
Yet, Bill, that is not the problem of the XML/XSLT model,
is it? That
model is really cool in separating the model from the
view. Indeed,
that model is great at separating the view data from the view
presentation. I am not sure what the app you worked on did, but I
think the idea behind the XML/XSLT model is terrific.
Essentially, as
I undestand it, the XML is sent and is in some "language" that the
client may or may not understand. So, the XSLT contains a crash
course in the language. That is way cool from my perspective.
Jack
P.S. I really liked Eddie Bush's Jedi Knight take on development.
That is quite true in my experience. Usually these
metaphors break
down pretty fast. That one held up pretty good.
Probably due to the
master Campbell being behind the mythology of Star Wars.
On Mon, 15 Nov 2004 09:43:19 -0500, Bill Siggelkow
<[EMAIL PROTECTED]> wrote:
Sorry, I haven't been following this thread, but I tend
to agree with
you. I worked on an app that used XML/XSLT to achieve
"purity" -- and
what resulted was a lot of this "view helper" data coded
into the "pure"
XML document; defeating the premise behind separation of
the model and view.
-Bill Siggelkow
Daniel Perry wrote:
I think the idea that MVC architecture should have a
'dumb view' is totally
wrong. The view should be as smart as possible.
MVC should separate the M, V and C. With a really smart
view you dont have
to do any preparation for the view in the controller.
If you have a dumb
view then you have to prepare the data in the
model/controller so that the
view can cope with it. Surely this is wrong as you are
doing view
processing outside of the view. Personally i think ALL
view processing
should be done in the view: the view code (be it jsps,
java, xml/xsl, etc)
should take model data, and produce a view of that data
- and it should be
flexible.
The problem with a smarter (or better worded: more
capable) view is that
people start doing things in the view which shouldnt be
done there, such as
database access. I dont think this is down to a problem
with the view
technology, just a lack of education on the users part.
Arguing that the
view should dumbed down to stop this problem arising is
like saying that
cars should only be able to do 70mph because that's all
they can legally do.
For example, a poject i am responsible has a lot of code
in the model beans
that was put there pre jstl for formatting things like
dates, or text. So
you have getStartDate() which returns a date, and
getFormattedStartDate()
which returns a formatted string. This code should be
in the view as it is
purely for view purposes, but i made the decision to
bodge it into the model
as it was nicer than using java code in the jsps. There
are various other
methods - such as retrieving chunks of text with \n into
<br>, which can now
mostly be handled with jstl.
Daniel.
-----Original Message-----
From: Rosenberg, Leon [mailto:[EMAIL PROTECTED]
Sent: 15 November 2004 13:44
To: Struts Users Mailing List
Subject: AW: talking about paradigms
No, but what about
<c:out value="${library.books[25].page[5].title}" /> ?
(not sure about the syntax).
whats the problem?
MVC usually allows 'read-only access to model' for the view
Also the question is, what you expose to the view.
If you are afraid that somebody will misuse the
library entries -
don't
expose them.
I suppose MVC was the reason for JSP EL not to allow
arbitrary method
invocations. But I'd love to have such anyway ;)
...
And what about database access tags?
You mean the jstl tags? They are there for quick and dirty.
If you don't change anything in the database though,
it still okay to
MVC.
If you don't want it, don't expose your database in
the first place ;)
The problem is, that if you give a user the possibility
to misuse your
framework - he will.
And EL gives jsps more power than a dumb view should
have. And if your
view isn't just layouting out the data, but performing
nearly complex
operations, it's not dumb anymore, and a smart view
doesn't fit into the
MVC.
If the user is allowed to break the paradigm he will.
If you have an architecture, which is built on a
paradigm (and any good
architecture is) you can't allow the developers to
break the paradigm,
or
the architecture will stop working one day, without
obvious reasons.
It's probably why there are no pointers in java, even
pointers adds cool
features to the language.
Regards
Leon
==////==
--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston,
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497
==============================================================================
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==============================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
