Personally, I don't plan to write a set of custom tags for
Struts 2.0. I would expect Struts 2.0 to be written in such a
way that custom tags (or Velocity tools) are not needed. But
if they were needed, and someone wrote a set that was popular
within our community, then I would consider
Oh well, I guess I'll look elsewhere for a framework.
If you can only use a framework that only bundles everything into one monothlitic
distribution, then yes you should. We tried that, and it is clearly not working. If
monolithic is the only way we could do things in the future, then I would
But what about when the V directly communicates with the C? This all
started with the cancel tag. It is very much a struts specific tag
that tells the controller that the action should be cancelled. So, in
this case, the taglib is required by the controller. Otherwise, a
different mechanism
I know I will get ignored or flamed on this, but here I go. My apologies in
advance if I offend anyone.
Before I start, I have made more than a couple of attempts at contributing
code, all of which have been ignored or pushed off to irrelevant projects.
I do wish this philosophy would get
--- Edgar P Dollin [EMAIL PROTECTED] wrote:
I know I will get ignored or flamed on this, but here I go. My
apologies in
advance if I offend anyone.
Before I start, I have made more than a couple of attempts at
contributing
code, all of which have been ignored or pushed off to irrelevant
From: Edgar P Dollin [mailto:[EMAIL PROTECTED]
2) JSTL is a waste of time. The reason I say this, not counting the
non-java people, is if you can write x number of lines of
useful code per
hour, with jstl that is reduced by a factor greater than 1 due to type
checking, refactoring
This contradicts point 1. If using JSTL tags is a waste of time, so is
using Struts tags.
Absolutely not. There is no logic in the view layer of the struts tags.
JSTL assumes you have to put the object in the scope, know something about
it in order to traverse it etc.
If you want your
So you would have to view be disconnected, and therefore when changes occur
in the business objects have only testing and a human mind connect the two
? Considering the poor shape of open source view level testing tools
this argument seems to be resting on shaky grounds.
Edgar
the
support would go up as well.
Edgar
-Original Message-
From: Don Brown [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 23, 2004 11:25 AM
To: Struts Developers List
Subject: Re: PATCH: html:cancel tag. Made a javascript version for
submitt ing
Please, someone fork the taglibs! :) I
Speak for yourself, I use Struts-EL and JSTL quite happily. One day I
would like to generate XML for the view and use XSLT to transform it
into HTML to which a CSS is applied, but I don't yet know how.
There are already solutions for this although this seems like a problem
waiting to happen.
I understand your point, although I don't know why you think it is
important. I guess I just disagree.
Sorry to have made the posting.
Edgar
-Original Message-
From: Michael Rasmussen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 23, 2004 2:43 PM
To: [EMAIL PROTECTED]
Subject: RE:
So, again, what if the cancel button (the patch that started this
whole thread) was patched to allow the proposed behavior, but didn't
require javascript? Meaning, it used javascript if possible, and if
the browser didn't use it provided the old/default method?
The javascript in question is
Thanks.
As to your prior point, I will explain why a goal of being able to swap the
view and controller is of a lower priority to me than having an integrated
set of tags with the controller.
Work gets planned and paid for by project. A typical project would be to
web enable or web service
From: Nathan Bubna [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: PATCH: html:cancel tag. Made a javascript version for
submitt ing
Date: Wed, 23 Jun 2004 13:23:14 -0700
Edgar P Dollin said:
...
As to your prior
14 matches
Mail list logo