Not sure; can't tell by looking at the API docs.
Probably, though.
Ultimately I'd like the property config names to be a path to a config
object/property--some may already be, I haven't really started looking at
those bits.
I'd like the ability to define everything hierarchically, in one place,
2011/12/11 Dave Newton :
> I'm fine with that; there is already a provider interface in
> XWork--not sure where the property file config comes from, haven't dug
> in.
DefaultPropertiesProvider and LegacyPropertiesConfigurationProvider ;-)
> A property file wouldn't work really well as a struts.xm
I'm fine with that; there is already a provider interface in
XWork--not sure where the property file config comes from, haven't dug
in.
A property file wouldn't work really well as a struts.xml replacement.
I guess I just don't see the value in a properties file at this point.
I was planning on d
I wonder if making configuration pluggable would make sense. Then we could
provide XML and Properties configuration plugins and others could add
Database backed or Groovy configuration plugins if desired.
(*Chris *)
On Dec 11, 2011 10:20 AM, "Dave Newton" wrote:
> On Sun, Dec 11, 2011 at 1:17
> We recommend XML configuration, and having multiple configuration
> points is confusing. I just don't see the point.
OK, it was just for the sake of curiosity.
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For addi
On Sun, Dec 11, 2011 at 1:17 PM, Maurizio Cucchiara
wrote:
>> 1) Can we drop the `.properties` config and move to XML exclusively?
>
> Could you delve deeper into the matter? Personally I have not ever
> used properties stuff, but it is my personal taste (though I see very
> few people use it), I
> I lost the wiki page where we were discussing things; can someone
> repost that link?
Sure,
https://cwiki.apache.org/WW/struts3planning.html
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-
> 1) Can we drop the `.properties` config and move to XML exclusively?
Could you delve deeper into the matter? Personally I have not ever
used properties stuff, but it is my personal taste (though I see very
few people use it), I would like to understand why properties file are
a good candidate to
I lost the wiki page where we were discussing things; can someone
repost that link?
How about things marked deprecated, like the old filter, some methods, etc?
I'm also wondering if the .ng filters should be moved into a
non-.ng-package? If the old ones are deprecated and removed, why
differentia
+1
Thats a good point for the next Major release.
Johannes
-
web: http://www.jgeppert.com
twitter: http://twitter.com/jogep
--
View this message in context:
http://struts.1045723.n5.nabble.com/Two-quickies-about-configuration-property-names-tp5063501p5064102.html
Sent from the Struts - Dev
10 matches
Mail list logo
