On Fri, 4 Feb 2005 08:57:05 +0100, Oliver Zeigermann
[EMAIL PROTECTED] wrote:
On Fri, 04 Feb 2005 15:52:16 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
Isn't it about time to give Digester2 a place in SVN, so I can either
create patches against it or directly commit to it. What about a
On Fri, 2005-02-04 at 08:57 +0100, Oliver Zeigermann wrote:
On Fri, 04 Feb 2005 15:52:16 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
Do you have commit rights to Digester? If not, I'd be happy to propose a
vote...
Well, not quite sure, how this is handled, but as I have commit access
On Fri, 04 Feb 2005 21:19:46 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
Digester2 is just me so far, though. I'm happy for you to commit to the
digester2 directory, and don't think there is anyone else you need to
ask.
Cool. I will need to do some work for money the next two weeks, but
As you've discovered, at the technical level Commons karma is
project-wide. Socially, the practice has been to do exactly what
you've done -- ask to participate and get accepted by the other
developers working on that package.
+1 on Oliver for Digester. I wish I had time to participate -- the
Not sure if it's been discussed already, but I'm very much in favor of this
(from the Wiki):
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
(oops, wrong button)
Not sure if it's been discussed already, but I'm very much in favor of
this
(from the Wiki):
' It would be nice for SetProperties and SetNestedProperties rules to
automatically map xml attributes and element names like foo-bar to bean
properties of form fooBar. '
It's
On Fri, 2005-02-04 at 10:45 -0700, Wendy Smoak wrote:
(oops, wrong button)
Not sure if it's been discussed already, but I'm very much in favor of
this
(from the Wiki):
' It would be nice for SetProperties and SetNestedProperties rules to
automatically map xml attributes and element
From: Simon Kitching [EMAIL PROTECTED]
' It would be nice for SetProperties and SetNestedProperties rules to
automatically map xml attributes and element names like foo-bar to bean
properties of form fooBar. '
If you feel like having a go at this yourself, I would be very happy to
see a patch.
On Thu, 03 Feb 2005 15:38:30 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
On Thu, 2005-02-03 at 02:11 +0100, Oliver Zeigermann wrote:
On Thu, 03 Feb 2005 11:39:01 +1300, Simon Kitching [EMAIL PROTECTED]
wrote:
I was also wondering, there may be occasions where it is desirable to
Hi Oliver,
I look forward to seeing your ideas on stringifying trees of elements.
The Rule (Action) classes interact with domain-specific (user) classes
via BeanUtils and reflection. I don't see any alternative, except for
the pre-processor type xml mapping tools, or runtime bytecode
--- Simon Kitching [EMAIL PROTECTED] wrote:
On Wed, 2005-02-02 at 20:45 -0800, Reid Pinchback wrote:
Of course if someone can demonstrate that non-namespace-aware parsers
*are* still useful then I'll change my mind.
Just to clarify, since I was being sloppy before (I gotta
stop typing in
Hi Simon!
On Thu, 03 Feb 2005 23:57:30 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
I look forward to seeing your ideas on stringifying trees of elements.
Isn't it about time to give Digester2 a place in SVN, so I can either
create patches against it or directly commit to it. What about a
On Thu, 2005-02-03 at 23:36 +0100, Oliver Zeigermann wrote:
Hi Simon!
On Thu, 03 Feb 2005 23:57:30 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
I look forward to seeing your ideas on stringifying trees of elements.
Isn't it about time to give Digester2 a place in SVN, so I can either
On Fri, 04 Feb 2005 15:52:16 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
Isn't it about time to give Digester2 a place in SVN, so I can either
create patches against it or directly commit to it. What about a
branch in commons proper? Or at least the sandbox?
Done.
Do you have
On Wed, 02 Feb 2005 18:28:04 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
On Wed, 2005-02-02 at 15:04 +1300, Sharples, Colin wrote:
- Why is Action an abstract class?
So that we can later add new functionality to Action without breaking
custom Action subclasses that users have
One section of the release notes says:
The Digester now *always* uses a namespace-aware xml parser.
I was wondering why this is. There are a lot of XML parsers
out there, and some of them have done things like trade
namespace awareness for performance. If somebody has a
application where
--- Oliver Zeigermann [EMAIL PROTECTED] wrote:
On Wed, 02 Feb 2005 18:28:04 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
My major concern is that if we are going to warn people not to implement
the Action interface,
then what really is the point of providing it in the first place? As I
On Wed, 02 Feb 2005 14:48:42 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
- Wouldn't it be possible (and even desirable) to have a more general
Pattern class instead of a String in Digester#addRule?
Can you explain more?
Well, RuleManager is an abstract class (discussion abstract class vs.
Hi Oliver,
On Wed, 2005-02-02 at 15:22 +0100, Oliver Zeigermann wrote:
On Wed, 02 Feb 2005 14:48:42 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
- Wouldn't it be possible (and even desirable) to have a more general
Pattern class instead of a String in Digester#addRule?
Can you explain
My major concern is that if we are going to warn people not
to implement the Action interface,
then what really is the point of providing it in the first
place? As I said above, I just cannot
think of any situation where a class would want to be an
Action *and* extend some other class.
On Wed, 2005-02-02 at 06:04 -0800, Reid Pinchback wrote:
--- Oliver Zeigermann [EMAIL PROTECTED] wrote:
On Wed, 02 Feb 2005 18:28:04 +1300, Simon Kitching [EMAIL PROTECTED]
wrote:
My major concern is that if we are going to warn people not to implement
the Action interface,
then
On Thu, 03 Feb 2005 11:39:01 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
I was also wondering, there may be occasions where it is desirable to
have the full body *including tags* passed in a call back. This would
mostly apply in mixed context tags where text is mixed with style
On Thu, 2005-02-03 at 02:11 +0100, Oliver Zeigermann wrote:
On Thu, 03 Feb 2005 11:39:01 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
I was also wondering, there may be occasions where it is desirable to
have the full body *including tags* passed in a call back. This would
mostly
On Wed, 2005-02-02 at 05:48 -0800, Reid Pinchback wrote:
One section of the release notes says:
The Digester now *always* uses a namespace-aware xml parser.
I was wondering why this is. There are a lot of XML parsers
out there, and some of them have done things like trade
namespace
--- Simon Kitching [EMAIL PROTECTED] wrote:
Supporting namespaces in an xml parser seems very simple to me. I think
it much more likely that only antique and unmaintained parsers fail to
support namespaces. And people who are determined to use antique and
unmaintained parsers can just stick
On Wed, 2005-02-02 at 20:45 -0800, Reid Pinchback wrote:
--- Simon Kitching [EMAIL PROTECTED] wrote:
Supporting namespaces in an xml parser seems very simple to me. I think
it much more likely that only antique and unmaintained parsers fail to
support namespaces. And people who are
Simon Kitching wrote:
BTW, should we contact the car companies, and tell them their customers
prefer suffixes?
Focus Ford
Mustang Ford
Thunderbird Ford
(I'm mostly kidding...)
I think the analogy is incomplete, you forgot the objet being qualified
by the brand. Would you say
Car Ford Focus
--- Simon Kitching [EMAIL PROTECTED] wrote:
Does this mean you prefer Action to Rule? I certainly expect to hear
from people who want to keep the current names...
I'm not wedded to Rule but I do have a concern about Action.
I suspect it could make Struts code rather confusing.
--- Simon Kitching [EMAIL PROTECTED] wrote:
Ok, we'll see what the general consensus is. I happen to personally like
prefixes rather than suffixes, but will go with the majority opinion.
I vote for prefixes.
That sounds reasonable. However I do dislike having mutual dependencies
between
Reid Pinchback wrote:
I strongly agree. Cyclic package dependencies seem
unimportant when you only have a few classes, but as the
amount of code grows, you quickly find that testing and
refactoring because much more difficult than it had to be.
Can you give an example of a difficult refactoring
Simon Kitching wrote:
Does this mean you prefer Action to Rule? I certainly expect to hear
from people who want to keep the current names...
No preference there, [and I'll get used to prefix/suffix, whichever way it
goes, it's not THAT big of a deal, but you asked...]
--
Wendy Smoak
Sure thing. Just to make it easier to envision, let's get
packages out of the equation. Just think about cyclic
dependencies between two classes in the same package.
That is enough to show the problem; packages just add complexity
because the dependencies can be much harder to detect visually
I very much like that and think it really is straight forward.
Comments:
- Why is Action an abstract class?
- Wouldn't it be possible (and even desirable) to have a more general
Pattern class instead of a String in Digester#addRule?
- I like the bodySegment vs. body design :)
- I like the no
On 2005-01-31 9:59:52, Simon Kitching wrote:
As I mentioned a few months ago, I've been working on some ideas for
Digester 2.0. I've put some code and notes up on
http://www.apache.org/~skitching
Simon,
Joran classes and documentation mention that it is influenced by
Digester. Is your design
On Tue, 2005-02-01 at 20:40 +0100, Ceki Gülcü wrote:
On 2005-01-31 9:59:52, Simon Kitching wrote:
As I mentioned a few months ago, I've been working on some ideas for
Digester 2.0. I've put some code and notes up on
http://www.apache.org/~skitching
Simon,
Joran classes and
Hi Oliver,
On Tue, 2005-02-01 at 18:04 +0100, Oliver Zeigermann wrote:
I very much like that and think it really is straight forward.
Comments:
- Why is Action an abstract class?
So that we can later add new functionality to Action without breaking
custom Action subclasses that users have
- Why is Action an abstract class?
So that we can later add new functionality to Action without breaking
custom Action subclasses that users have written. As long as we can
provide a suitable default implementation in the Action
abstract class,
everything runs smoothly.
One example is
On Wed, 2005-02-02 at 15:04 +1300, Sharples, Colin wrote:
- Why is Action an abstract class?
So that we can later add new functionality to Action without breaking
custom Action subclasses that users have written. As long as we can
provide a suitable default implementation in the
On Tue, 2005-02-01 at 16:20 +0100, Emmanuel Bourg wrote:
Reid Pinchback wrote:
I strongly agree. Cyclic package dependencies seem
unimportant when you only have a few classes, but as the
amount of code grows, you quickly find that testing and
refactoring because much more difficult
XXXRule -- ActionXXX for all XXX
By using a prefix instead of a suffix, all the Action classes group
nicely together in the javadoc.
I tend to prefer the type as a suffix, to keep them grouped in the
javadoc I would rather use an action(s) subpackage. With or without
's' is another debate ;)
hi simon
my main development machine blew up last week and i'm still struggling
to get up and running on a secondary one.
i haven't had a chance to look at the code yet (and it might be a fair
while before i do) but i'd like to suggest that (when the time comes)
you consider developing in
On Mon, 2005-01-31 at 22:20 +, robert burrell donkin wrote:
hi simon
my main development machine blew up last week and i'm still struggling
to get up and running on a secondary one.
i haven't had a chance to look at the code yet (and it might be a fair
while before i do) but i'd
On Mon, 2005-01-31 at 11:23 +0100, Emmanuel Bourg wrote:
XXXRule -- ActionXXX for all XXX
By using a prefix instead of a suffix, all the Action classes group
nicely together in the javadoc.
I tend to prefer the type as a suffix,
Ok, we'll see what the general consensus is. I happen to
From: Simon Kitching [EMAIL PROTECTED]
Ok, we'll see what the general consensus is. I happen to personally like
prefixes rather than suffixes, but will go with the majority opinion.
Another vote for suffix - I prefer CallMethodAction to ActionCallMethod.
Will ActionFactory have all of the
On Mon, 2005-01-31 at 21:43 -0700, Wendy Smoak wrote:
From: Simon Kitching [EMAIL PROTECTED]
Ok, we'll see what the general consensus is. I happen to personally like
prefixes rather than suffixes, but will go with the majority opinion.
Another vote for suffix - I prefer CallMethodAction
On Mon, 2005-01-31 at 21:43 -0700, Wendy Smoak wrote:
From: Simon Kitching [EMAIL PROTECTED]
Ok, we'll see what the general consensus is. I happen to personally like
prefixes rather than suffixes, but will go with the majority opinion.
Another vote for suffix - I prefer CallMethodAction
46 matches
Mail list logo
