There are several companies that would agree ;-)
On Thu, 2004-10-07 at 13:29, Paul Speed wrote:
> It was bound to happen... sometimes it would be nice to have an "unsend"
> button. :) Just need to work out that whole time/space continuum thing.
> -Paul
>
> [EMAIL PROTECTED] wrote:
>
> > Bah2
Could we add code to either the request processor or the action servlet
to add the default message resource defined in a struts.config to a
scope (app/session/request) under the key
"javax.servlet.jsp.jstl.fmt.localizationContext", so the default bundle
works with fmt:message without having to do a
That is basically what that set does.
This should be standard behavior of the default request processor. (If
not already.)
- Mike
On Thu, 2004-10-07 at 14:28, Mike Stanley wrote:
> Could we add code to either the request processor or the action servlet
> to add the default message reso
quick thoughts/suggestion - my pizza just came ;-)
* Action Form - Form Context
How about adopting XForms (http://www.w3.org/MarkUp/Forms/) as the model
for all Action Forms? This contains a model for representing everything
you spoke about in your email - basically the seperation of purpose
Ted Husted wrote:
On Sun, 10 Oct 2004 16:04:40 -0400, Mike Stanley wrote:
Another simple suggstion I would like to make (enhancement request) -
it would be extremely powerful to add the property support that
exists for plugin configuration, to action and request processors.
This can go along
Joe Germuska wrote:
At 6:18 PM -0400 10/10/04, Mike Stanley wrote:
Ted Husted wrote:
On Sun, 10 Oct 2004 16:04:40 -0400, Mike Stanley wrote:
Another simple suggstion I would like to make (enhancement request) -
it would be extremely powerful to add the property support that
exists for plugin
I count currently 283 open issues.
I'm new to this community but am an experienced struts developer - and
senior enterprise Java developer.
Just a heads up, I'm going to be going (slowly - little here, a little
there) through the bug list and commenting on issues.
i have no vote, no karma, j
On Tue, 2004-10-12 at 11:27, Joe Germuska wrote:
> >>Note that, at least with ActionConfigs, there is an important
> >>difference between "type" and "className". "className" refers to
> >>the type of the ActionConfig itself, should you want to use a
> >>subclass (say, for custom properties) wh
> The other thing I would add is strong debuggability. Is it true that Tapestry's web
> debugging is the best of the current crop of web application frameworks?
"Line precise error messages" - are very useful. This however, is not
as easy with a JSP engine, given the nature of JSP (template ->
On Wed, 2004-10-13 at 23:18, Martin Cooper wrote:
> On Wed, 13 Oct 2004 06:26:00 -0400, Ted Husted <[EMAIL PROTECTED]> wrote:
> > On Tue, 12 Oct 2004 15:22:38 -0700, Martin Cooper wrote:
> > > That said, I would really like to see us all stick together for as
> > > long as possible, and not diverg
On Thu, 2004-10-14 at 20:47, Joe Germuska wrote:
> >Struts relies on Jakarta Commons stuff. So I think the pizza base
> >is only good as the quality of the ingredients on top of it.
> >Is there a way, for example, to get precise line error when,
> >say the Digester cant intercept the struts-config
On Fri, 2004-10-15 at 00:22, Joe Germuska wrote:
> >Hmmm You may be thinking of HiveMind, which is the refactored
> >IOC-type container that grew out of Tapestry. HiveMind is similar in
> >focus to Spring, but follows an approach that is similar to Eclipse.
> >(separation of configuration, se
On Sat, 2004-10-16 at 14:13, Martin Cooper wrote:
> On Sat, 16 Oct 2004 14:09:59 -0400, Paul Speed <[EMAIL PROTECTED]> wrote:
> > It is kind of nice to have revision information in the javadocs though,
> > isn't it? I've at least found it useful in my own projects.
>
> The thing is that in Subve
it confuses people who
> think he's voting, when we are really only discussing.
>
> -Ted.
>
> On Sat, 16 Oct 2004 14:59:52 -0400, Mike Stanley wrote:
> > -1 -- knowing the build number associated with the javadoc you are
>
>
>
Hi Michael,
I don't understand you're proposal. FileItem (from commons upload) is
an interface with a factory. FileUploadBase (the parser) is abstract
with different implementations. Why would you wrap the interface
instead of simply creating a new concrete implementation of the above
mentioned
portlet.xml :-)
Basically you have content (may be space or blank lines) before the
prolog . I've also heard of this error message
showing up if you had content after the prolog but before the open
root. (I've never seen that though ;-) Here's a forum that discusses
this issue.
http://forum.ja
I'm -1 on this.
By default, I think the ActionForms toString should be the default
Object.toString. If you need/desire you can easily still create a base
support class for your projects that implement the reflection based
toString you suggest.
The reason I'm anti- this is that it will cause
-1 - use filters. (but my vote is just opinion and has no real weight)
- Mike
On Wed, 2004-10-06 at 23:52, James Mitchell wrote:
> I am also -1 on this. Why should I have to subscribe to so many lists?
>
>
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> Well, that's the reason I put the idea out there... I can't think of every possible
> angle to look at it from... If I thought I could, I wouldn't need to solicit
> opinions in the first place.
No one possibly could. Which is why Open Source is such an effective
model for software development
> With the static method I can apply my toString implementation to any object that
> comes along - just what you need for debugging. I just wonder why the Apache
> commons-beanutils does not provide such a method, and someone mentioned it might be
> in commons-lang, but I could not find that ei
Is this really more convenient than simply overriding toString() ?
- Mike
On Thu, 2004-10-07 at 09:45, Kris Schneider wrote:
> This should always give you the equivalent of Object's toString method:
>
> Integer.toHexString(System.identityHashCode(obj)).
>
> If anything gets added, I'd rather s
Hiran Chaudhuri
> SAG Systemhaus GmbH
> Elsenheimer Straße 11
> 80867 München
> Phone +49-89-54 74 21 34
> Fax +49-89-54 74 21 99
>
>
>
>
> > -Original Message-
> > From: Mike Stanley [mailto:[EMAIL PROTECTED]
> > Sent: Donnerstag, 7. Okto
22 matches
Mail list logo
