he same time, it allows people to fully
experiment with both alternatives. This would only be worthwhile during the
transition. Later releases wouldn't need this.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
new Object[] {getBodyContent().getString()} );
I believe the functionality in this block is basically what
"BeanUtils.populate()" does, although with a little more overhead.
--
===
David M. Karr ; Java/J2EE/XML/
cent
mention of this problem in either list.
I tried changing the installed file to not have the locale suffix, but that had
no effect.
--
=======
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-ma
Craig> Doing this would seem to avoid the need for dual libraries. Does that
Craig> make sense?
One reason I thought dual libraries would be logical is that the JSTL requires
JSP 1.2 (correct?). In order for Struts to still allow using JSP 1.1, don't we
need to have a library av
pecific infrastructure to "make the choice", by soft-coding the
choices into the application configuration.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
String.class, this, pageContext));
}
catch (NullAttributeException ex)
{ setArg1(null); }
...; // Others
}
}
--
An example usage would be:
--
------
--
=
>>>>> "Craig" == Craig R McClanahan <[EMAIL PROTECTED]> writes:
Craig> On 16 Jul 2002, David M. Karr wrote:
>> I don't know how much thought has yet gone into how Struts and JSTL can work
>> together. I haven't noticed muc
for what would
make sense.
Many of the attributes that would take EL values won't even have to have their
name changed. For instance, the "key" attribute of "bean:message" is fine as
it is. In the case of this tag, the "name" and "property" attribut
, as opposed to being an
entirely separate library. We should be able to release it as a standalone
library later.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
, which is called from the derived "doStartTag()" method. Even that code
will be mostly boilerplate. The more difficult cases will be where I really
have to change what the base "doStartTag()" or "doEndTag()" methods do.
--
===
won't be used for generating the tag
libraries, only for documentation generation.
I'll provide more information as I get closer to completion (or what looks like
completion to me).
Any comments or questions?
--
==
>>>>> "Craig" == Craig R McClanahan <[EMAIL PROTECTED]> writes:
Craig> On 22 Jul 2002, David M. Karr wrote:
>> It's occurred to me that if I'm building a tag library that would be used
>> alongside the JSTL, there's not
which provides
all that is needed for that. I specifically needed to include Xalan, however,
as JDK1.4 doesn't make the Xalan "XPathAPI" classes visible, which I'm using
for accessing generated attributes (sort of heavyweight for that, but it makes
it very straightforward).
--
at at your code when I get a chance. Thanks for the pointer.
You'll hear about it on struts-dev. Hopefully, it will be integrated into
Struts as a contrib project.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
r library to get the functionality I'm not
porting. I believe that can work, although I'm not directly testing for that.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
quot; attribute and others could still use the
EL engine, just not the "name/property" functionality.
Does anyone have any ideas about this?
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
things, one in JSP, and the other in HTML).
Unfortunately, a change like this will require changing the base Struts tag.
In the case of "CheckboxTag" (and probably others), the current value lookup is
done directly in its "doStartTag()" method, with no comparison of "value"
against null check to bypass it (which is the case in other tags, like "size"
and "message", for instance).
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
dhay> all this made it easier to plug stuff in? ;-)
dhay> Or am I missing something...?
Look at the "struts-config_1_1.dtd". You'll see a "processorClass" attribute
in the "controller" element. This removes the need to subclass ActionServlet.
--
bute was present. The old meaning if "name" was
present, and the new meaning if "name" is not present. The "indexed" attribute
could only be present if the "name" attribute was present.
This would provide a transitional strategy, even while using the Strut
>>>>> "David" == David M Karr <[EMAIL PROTECTED]> writes:
>>>>> "Jing" == Jing Zhou <[EMAIL PROTECTED]> writes:
Jing> The convention (see JSTL spec 2.2.1) is to use the name "var" for attributes
Jing> that
()" method and a new no-args constructor (I
would guess that none of the tags have a defined constructor).
Is there a good reason for how this currently works?
--
===========
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROT
>>>>> "Craig" == Craig R McClanahan <[EMAIL PROTECTED]> writes:
Craig> On 28 Jul 2002, David M. Karr wrote:
>> Is there some reason the Struts custom tags have redundant initializations of
>> their instance variables, once as implicit in
is there a predefined
"style" in XEmacs that matches the Apache coding format?
--
=======
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For a
test resources in memory, as opposed to using an external file. I had an error
tag of "error.misc", but in order to get this to work, I had to store a key of
".error.misc" in my MessageResources.
--
===
David M. K
erstand. I've adjusted my HMMR class to reflect this, so usage of it
is a little clearer.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
45216
I was just about to write a reply to myself saying that Jalopy works fine for
this. It has some pretty interesting optional features, but it does exactly
what I need out of the box.
--
=======
David M. Karr ; Java/J2E
put on stdout. I
added a "" element specifying this class (with a "verbosity" of "4"),
in ADDITION to the "FileLogger". The result was that I saw lots more
information coming to stdout, but not my "log.debug(...)" lines.
--
=
, the method that it sends them to,
"RequestUtils.message()", does check for null.
There's probably lots of cases like this that still work, even though
"release()" leaves them in a different state than initial construction.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
; original
Jing> beauty of Struts and even the design could enhance the current html tags
Jing> without
Jing> having to create a "parallel" library in the end (Did someone say that
Jing> before?)
The only constant is change. There is movement towards using the JSTL. The
goal is to eventually have a Struts tag library that works cleanly with the
JSTL. This "parallel" library is only a transition strategy.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
he "collection" attribute of some tags. Since from
the point of view of JSP, an EL expression is just a string, that wouldn't map
directly to a javabeans set method that takes a Collection. In these cases, I
believe I'd have to implement a BeanInfo class that specifies a method in my
subclass, like "setCollectionExpr()" or something like that, which I can map
into the base class "setCollection()" method.
I'd appreciate any useful comments or suggestions.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
'm not exactly certain what purposes this value is applied to. If that's just
a symbolic value that will be used as the taglib URI, and it doesn't have to
really exist, then that'll probably be fine.
--
===
David
CVS, and is based on the 1.1-b2 code base.
I'd like to get this "out there" in the hands of people who can use it, and who
can help to evolve it forward.
Advice? Help? Direction?
--
===
David M. Karr ; Java
en, I just didn't want that to be another reason to delay
getting this to other people.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
ng to do with "tunnelling" not being properly set
up, but I'm unsure.
--
=======
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
s, will that cause any
problem?
--
=======
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
uld be ready to commit, unless someone
can point out something else I should do before I commit.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>>>>> "David" == David M Karr <[EMAIL PROTECTED]> writes:
David> Once I get various administrative details straightened out in my local
David> repository, is it reasonable to assume that I would move forward with
creating
David> a "con
hat the ASL header is in the sources files before
Martin> committing them.
Yes, I was going to add the file headers before committing, along with at least
basic javadoc. I assume I can just copy the header from one of the Struts
source files?
--
=
tests completed.
I'll start on making standardization changes tomorrow evening. Hopefully none
of the changes I make in the next few days will have any real effect on the
resulting code.
--
=======
David M. Karr ; Java/J2EE/
eally supposed to go
here?
--
===========
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
get to a Struts release (1.1-b3, or 1.1)?
--
=======
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
date the main build.xml file to include struts-el in the new
"contrib"
craigmcc> directory, so that the binaries will be included with nightly builds.
Oh, yeah, I forgot about that :) . That'll be sort of important.
--
=====
" file, just like the top-level
build. Will someone create that manually, or what?
--
=======
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
happen if someone tries
to build it with a 2.2 servlet.jar?
--
=======
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>>>>> "Craig" == Craig R McClanahan <[EMAIL PROTECTED]> writes:
Craig> On 1 Oct 2002, David M. Karr wrote:
>> Date: 01 Oct 2002 21:14:26 -0700
>> From: David M. Karr <[EMAIL PROTECTED]>
>> Reply-To: Struts Devel
>>>>> "Craig" == Craig R McClanahan <[EMAIL PROTECTED]> writes:
Craig> On 1 Oct 2002, David M. Karr wrote:
>> Date: 01 Oct 2002 21:14:26 -0700
>> From: David M. Karr <[EMAIL PROTECTED]>
>> Reply-To: Struts Devel
nal tasks. I think this isn't useful here.
I'll remove that and check it back in.
--
===========
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
the base Struts tags to see if there are any attributes
they should be handling, but are not. I don't plan on doing this, as that
would be too mentally punishing :) .
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
uot;onmouseup" handler
>> is still commented out, as the bug in the base tag isn't fixed yet.
Craig> You're more than welcome to fix the bug in the base tag :-).
I thought it was likely I would do this, I just wanted to get the bug logged
first.
--
=
, boolean, or
float. Then I have to write a BeanInfo class, as the attribute in the "-el"
class has to be a String (int, boolean, and float are apparently automagically
translated). This doesn't happen very often. The only cases in Struts-EL
occurred with "collection" att
umber that I'm submitting code against, what is a
reasonable process for verifying the bug is "fixed" so I can resolve it? I can
easily test it in my distribution, but do I have to install and test it in the
next nightly build, or what?
--
===
ute on
"html:hidden".
Yes, I'm easily amused.
--
=======
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
ot; files are almost identical between the old version and the
CVS version.
Any particular local configuration files that might shed some light?
--
=======
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubsc
>>>>> "David" == David M Karr <[EMAIL PROTECTED]> writes:
David> I could use a hand figuring out what I did to break my Struts-EL unit test
David> process.
David> I decided to get back to building some more unit tests for Struts-EL tags,
but
>>>>> "Ted" == Ted Husted <[EMAIL PROTECTED]> writes:
Ted> Are you using Ant 1.5?
Yes.
--
=======
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail
cope.
How do you get them into any scope but "request"? The "Action.saveErrors()"
method doesn't appear to have an overloaded version taking a "scope" key.
Also note that it would be good if any changes to how "errors" works would also
be done in the &q
I've been adding more "exercises" to the Struts-EL exercise-taglib app, and I'm
finding some behavior I don't quite understand.
In the same JSP page, I have two "logic-el:iterate" loops, both of which
iterate through the same collection, the page attributes map ("${pageScope}").
One loop has an "
such), and I am working through it, but
James> wondering if I missed an email somewhere ?!?!?!?
What is happening?
--
=======
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto
hort run, it might
be more practical to do this.
--
=======
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
do more of the "Developer Guide" kid of thing,
and link more into the JavaDocs.
Ted> Right now, we're getting into a lot of dual maintenance. But first things
first.
I'm not sure what you mean here.
--
=
fish to fry for 1.1.0]
I do have other things to do, but I might be able to get this done. I'll leave
it like this for now.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e
o cover not only the Struts-EL
tags, but also the Struts tags which were NOT ported to Struts-EL, and which
JSTL tags and functionality can be used instead. Presently, I'm putting this
information into the "package.html" file at "org/apache/strutsel", as opposed
to in the info
vailable in the JSTL (not to
mention that attaching "role-checking" features to "logic:present" just seems
odd). However, when I look at it from a pragmatic viewpoint, I realize that's
less important than simple convenience.
--
t tag.
Could you trace this in the debugger?
I assume you've recently cvs updated?
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
d committing rough drafts of the top-level, bean-el, logic-el, and
html-el package.html files. They don't attempt to use any external links yet.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
quest to the group, to make management of Struts-EL a little easier.
Whenever you make a change which adds, deletes, or changes the type of, a
custom tag attribute, could you submit a bug report indicating that the
corresponding tag in Struts-EL needs to change?
--
======
at, and just using the Manager to "reload" your application,
after you added the references to "html-el:html"? If so, do a "remove" on the
application and reinstall it. If that works, I think this might be a
bug/feature in Tomcat, wrt reflection, classloading, and Be
beanInfoClass = ELHtmlTagBeanInfo.class;
and retest.
--
===========
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
ood someone
will want to use a plain DynaBean with this? One person who was looking for
this feature (who thought it was already supported in the JSTL) used as his
example JSP scriptlet code using plain BasicDynaBeans.
Any thoughts?
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
MAIL PROTECTED]
bugzilla> ReportedBy: [EMAIL PROTECTED]
I'll commit this in a day or so when I can finish the doc changes and additions
to the strutsel-exercise-taglib.
--
===
David M. Karr ; Java/J2E
not running 1.1b with JSTL.
Edgar> The only workaround I could find was to re-write the c:set as a very simple
Edgar> tag.
Did you post the exact code you're trying to compile, along with the exact
stack trace?
--
=====
ly, I don't see any way to provide this option to the "javadoc" task
in Ant, so I can at least (easily) see what it does.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED] ; SCJP
--
To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
y the JSP again to
re-populate the form fields. In the case of validation errors, Struts has a
shared mechanism for raising and displaying error messages.
--
=======
David M. Karr ; Best Consulting
[EMAIL PROTECTED] ; Java/Uni
h I'm genetically
incapable of), which would require considerable initial
setup, is this the best place to direct these?)
--
=======
David M. Karr ; Best Consulting
[EMAIL PROTECTED] ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)
Is it just supposed to be
in the CLASSPATH (I sort of doubt this)?
--
===========
David M. Karr ; Best Consulting
[EMAIL PROTECTED] ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>>>>> "Steven" == Steven D Wilkinson <[EMAIL PROTECTED]> writes:
Steven> "David M. Karr" wrote:
David>
David> I'd like to experiment with some ideas for modifying the "html:radio" tag.
David> Before I ma
x" component (although I'm not familiar
with the latter component yet). I would assume I would also need to provide
documentation and unit test patches. I would also make the patches against the
latest in CVS, instead of the 1.0.1rc1 source release.
What do you think?
--
===
David M. Karr ; Best Consulting
[EMAIL PROTECTED] ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>>>>> "David" == David M Karr <[EMAIL PROTECTED]> writes:
David> I've often been frustrated by some details of the "radio" and "checkbox"
tags.
David> I have some issues with the rules for producing the "name" of
x27;m taking a look at the contents of those builds, but there's one thing I want
to know: Is there some place where the console output from Ant for those builds
is stored, so I can see if something went wrong?
--
=======
David M.
7;ve confirmed the binary on the 17th has struts-el included, and the binary on
the 18th does not. So how do we track what really happened on a build for a
particular day?
--
=======
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMA
rking on some documentation which I
hope to put in the user guide, concerning indexed properties, mapped
properties, indexed tags, and indexed/mapped properties in Struts-EL.
--
=======
David M. Karr ; Java/J2EE/XML/Unix/
. Much of this length is from several versions of a
simple JSP page showing usage of this.
I'd like to add this as section 3.3.6, in the "Forms and FormBean Interactions"
section, titled "Indexed & Mapped Properties".
Any comments?
--
=======
heck for "AssignedTo" being equal to
"[EMAIL PROTECTED]" (in the box just above the "Sort By" box).
This will get you to a manageable list.
Then click "Submit Query" and browse through the results.
--
This will be my first release, and I'm willing to do what I can, although I'm
not sure what that will be.
--
=======
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED] ; SCJP
--
To unsubscribe
ppeared from the 8th
to the 14th, and appears to be alternating every other day. The last nightly
had it.
--
===========
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED] ; SCJP
--
To unsubscribe, e-mail: <mailto:[E
ugh being new to this exact sort of thing, I'm not quite sure what
that will be.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED] ; SCJP
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
th for slightly different reasons.
On that subject, wouldn't it be possible to write a tag library validator class
which could verify this? I've wondered whether some of these hard to
understand errors we get from the framework could be prevented by a tag library
validator class.
--
=
" tags. This doesn't help people who are forced to use
containers only supporting Servlet 2.2. Hopefully that set is becoming smaller
and smaller.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED] ;
pports if/elseif/else. The
>> expression language in JSTL makes logic easy that would be nasty with the
>> various logic tags.
>>
>>
>> ...
>>
>>
>> ...
>>
>>
--
==
usage). Writing a version of
"findAncestorWithClass" that takes a string instead of a Class is the first
step. You'd also have to deal with allowing subclasses of the tag types.
That's probably the ugliest part.
At this point, I really don't see the urgency.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED] ; SCJP; SCWCD
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
anyone envision any other situations in the Struts code where indirect
references to the JSTL would be convenient? That, at least, could give us some
additional perspective on this.
--
===
David M. Karr ; Java/J2EE/XML/
>>>>> "Craig" == Craig R McClanahan <[EMAIL PROTECTED]> writes:
Craig> On 4 Jan 2003, David M. Karr wrote:
>> Can anyone envision any other situations in the Struts code where indirect
>> references to the JSTL would be c
nt interfaces to those MBeans,
either as another web application, or through other interfaces (command-line,
etcetera).
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED] ; SCJP; SCWCD
--
To unsubscribe, e-
ing the tradeoffs, I like what java2html does, but I guess I don't see
enough value to making the output part of the distribution.
The primary value of this project is what you can do with it, not what's in the
source code.
--
========
so I wasn't able to get the associated
Struts-EL changes in until after 1.1b3 was tagged. I don't think that is a
real problem, but it will be a real problem if something like this happens for
the real release.
--
===
>>>>> "David" == David M Karr <[EMAIL PROTECTED]> writes:
>>>>> "David" == David Graham <[EMAIL PROTECTED]> writes:
David> The only added attribute was "cdata" that defaults to true on the javascript
David>
>>>>> "David" == David Graham <[EMAIL PROTECTED]> writes:
David> Is that a -1 for 1.1 or -1 for any release?
David> Dave
I very much want to see a 1.1 release very soon, I just don't think the release
candidate should be the 1.1b3 release.
>>>>> "David" == David M Karr <[EMAIL PROTECTED]> writes:
David> Is there an easy way to get the diffs or comments of all elements with
commits
David> since the 1.1b3 tagging?
If it's useful, I figured out how to get the diffs listing, at
ting
changes to the Struts nightly build (after 1.1), then we'd have the situation
of a Struts-EL release which had to be used with a nightly build of Struts, and
not the latest release.
--
===
David M. Karr ; Java/J2EE/
want another beta before RC1
James> Question 2:
James> +1 means you want struts-el included in RC1 and the final release.
James> +0 Who cares
James> -1 You want struts-el packages seperates with it's own release cycle
Q1: +1
Q2: +1
--
===
1 - 100 of 125 matches
Mail list logo
