Ted Husted wrote:
Craig R. McClanahan wrote:
- If a user attempts to remove() the key corresponding to a property,
throw IllegalArgumentException.
Can we make this an optional behavior?
Only if we make attribute-property transparency optional. That's what
the contract for org.apache.commo
Craig R. McClanahan wrote:
- If a user attempts to remove() the key corresponding to a property,
throw IllegalArgumentException.
Can we make this an optional behavior?
The contact for Map.get and Map.remove says that they will return null
if the entry is not present or if the value is null. T
Ted Husted wrote:
Craig R. McClanahan wrote:
We haven't released anything yet ... why not just check it in to the
o.a.c.c.impl package so we can all take a look. We need to
completely fulfill the Map contracts if we go this way, and I have
some concerns about that.
It's there. This one just
Craig R. McClanahan wrote:
We haven't released anything yet ... why not just check it in to the
o.a.c.c.impl package so we can all take a look. We need to completely
fulfill the Map contracts if we go this way, and I have some concerns
about that.
It's there. This one just delegates the Map met
Ted Husted wrote:
Craig R. McClanahan wrote:
The latter lets any Command lets any Context implementation be passed
in, but still provide generic access to the specialized properties
without casting. For example, if your Command is passed in a
ServletWebContext you can try:
Map map = (Map) c
Craig R. McClanahan wrote:
The latter lets any Command lets any Context implementation be passed
in, but still provide generic access to the specialized properties
without casting. For example, if your Command is passed in a
ServletWebContext you can try:
Map map = (Map) context.getAttributes
Ted Husted wrote:
Craig R. McClanahan wrote:
Do you think we should make a Catalog an optional property of a
Context? A lot of use cases would like to have a default spot to go
find one, and you can always have private conventions about what
other attribute keys might also point at other Cata
Craig R. McClanahan wrote:
Do you think we should make a Catalog an optional property of a
Context? A lot of use cases would like to have a default spot to go
find one, and you can always have private conventions about what other
attribute keys might also point at other Catalogs.
If we are talk
Ted Husted wrote:
Craig R. McClanahan wrote:
Far better would be to divide the procedural flow into small steps
that are externally configurable. And, let each step have its own
arbitrarily complex internal structure (by virtue of the fact that it
can be a Command or a Chain of its own). Oh,
Sgarlata Matt wrote:
Well my goal with this idea was to make applications less dependent on the
environment in which they run. The servlet environment can of course handle
everything that this Registry can, but it is in the presentation tier. I
think the Registry for the business tier should resi
- Original Message -
From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Friday, September 26, 2003 8:10 AM
Subject: Re: [Chain] DTD, Design Considerations, etc. (was Re: [Chain]
examples XML file ava
(I'm less annoying in this email I promise...)
- Original Message -
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, September 24, 2003 12:59 PM
Subject: Re: [Chain] DTD, Design
Sgarlata Matt wrote:
The conversation threads are getting kind of crazy, so I'm going to skip
inline quotes for parts of this.
Craig, now I do see your point about using the ConfigRuleSet to digest a
portion of
an arbitrary XML file. That is very cool, and now I understand why the
names of the XM
Sgarlata Matt wrote:
How about making a Register class which is an implementation of Context
which stores only references to Catalogs? We could make the registry itself
a singleton, and write in design notes that since the registry is shared
between apps, each app should store its Catalog(s) in an
Sgarlata Matt wrote:
Related to this, how come
Command.execute returns boolean instead of returning Command? If it
returned Command this would basically eliminate the need for a Chain
interface altogether. Chain would become a concrete implementation of
Command that repeatedly executed Commands u
> As I've thought more about the package, I don't understand why some
> design decisions were made. First let me say that I think of Chains
> as being an OO way to simulate procedural logic. Many of my comments
> will basically be concerning why some of the standard control flow
> abilities (if/t
The conversation threads are getting kind of crazy, so I'm going to skip
inline quotes for parts of this.
Craig, now I do see your point about using the ConfigRuleSet to digest a
portion of
an arbitrary XML file. That is very cool, and now I understand why the
names of the XML elements are config
17 matches
Mail list logo
