Ok, the problem here is a misunderstanding how the configuration
providers work. A configuration provider creates packageconfigs
populated with the appropriate information. Once all configuration
providers have provided their packages, the configuration instance
will create the runtime configura
Fixed. For future reference, snippets must begin with configured
prefixes in order to work. In this case, they weren't. Here are the
prefixes configured for the OpenSymphony Confluence instance:
Prefix URL
com.opensymphony.xwork2.
http://svn.opensymphony.com/svn/xwork/trunk/src/java/com/o
Something is not working right:
http://wiki.opensymphony.com/display/WW/IntRangeFieldValidator+Annotation
musachy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
>From a user's perspective, I am not sure I would like to see the cutoff be any
>Dojo widget-related tags, for as both Ian and Musachy have pointed out, you
>are now using dojo across themes and thus one core tag might get the boot in
>one or more themes due to its dojo javascript library implem
On Nov 22, 2006, at 10:36 AM, Ted Husted wrote:
I like the weekly opened and closed reports.
FYI, these are setup you might want to look in the moderation queue
as it doesn't seem like they're getting through.
Here's the schedule:
08 8 * * 1 $HOME/bin/jira_report.sh opened.vm 10030 S
That's a very good point. What about making the cutoff any Dojo
widget-related tags? This would include the calendar tag. I think it
would be ok to split this off, since it is in no way compatible with the
old calendar tag anyways.
We could use a very slimmed down version of Dojo for toolti
Just to complicate it further we have the special case of the
Autocompleter which has communication if it is used in the ajax theme,
and just javascript if in the simple theme (it should be xhtml). The
idea of having a custom dojo profile is good.I logged a jira ticket for
it a couple of weeks
As a user, I'm very much looking forward to the dojo 0.4.x calendar widget (or
something equally aesthetic/functional) that was previously discussed as being
tied to the date input tag(s). However that's accomplished... I just thought
you may want to hear from a user's perspective.
- Origi
On 12/19/06, Don Brown <[EMAIL PROTECTED]> wrote:
The tooltips could use another library, and either the calendar could
use a slimmed down version of dojo for that widget or another library.
The problem is currently our xhtml theme included dojo, which I kinda
regret. It does seem like there sh
The tooltips could use another library, and either the calendar could
use a slimmed down version of dojo for that widget or another library.
The problem is currently our xhtml theme included dojo, which I kinda
regret. It does seem like there should be a more clear separation.
Don
Ian Rough
Yes, they are implemented using Dojo.
musachy
Ian Roughley wrote:
Just thought of a possible downside.
Features that users may have expected as simple javascript / non-ajax,
for example tool tip and calendar, are (I believe) now implemented
using the dojo library. So there is not a clean sep
Just thought of a possible downside.
Features that users may have expected as simple javascript / non-ajax,
for example tool tip and calendar, are (I believe) now implemented using
the dojo library. So there is not a clean separation between those tags
that have communication and those that d
-Original Message-
From: Antonio Petrelli [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 19, 2006 2:36 AM
To: Struts Developers List
Subject: Re: Problems with Tiles 2 and WS 5
Stone, Sam ha scritto:
> 1)changed all my tiles-defs to use tiles-config_2_0.dtd instead of
> 1.1
>
Ok, I think I understand the use case, and using a map is definitely
cleaner than what I had done in the struts2 plugin - create a "wrapper"
for the actual context which allowed me to inject my own defaults (see:
http://svn.apache.org/repos/asf/struts/struts2/trunk/plugins/tiles/src/main/java/or
David H. DeWolf ha scritto:
Antonio,
I'm not sure I understand why we need to support both the context and
a map of defaults for retrieving config info for factories. It seems
redundant and thus confusing.
If we want to use a map, shouldn't we just remove the context all
together and have
Antonio,
I'm not sure I understand why we need to support both the context and a
map of defaults for retrieving config info for factories. It seems
redundant and thus confusing.
If we want to use a map, shouldn't we just remove the context all
together and have the client push all of the in
[EMAIL PROTECTED] ha scritto:
Hi guys
My apologies if I'm sending this e-mail to the wrong mailinglist. I was wondering if it's possible to add Struts 1.3.5 to the maven repository. I know there are 2 versions available (parent en core), but no matter what I try, I can't seem to download th
Hi guys
My apologies if I'm sending this e-mail to the wrong mailinglist. I was
wondering if it's possible to add Struts 1.3.5 to the maven repository. I know
there are 2 versions available (parent en core), but no matter what I try, I
can't seem to download them from the repository. If I
18 matches
Mail list logo
