Validators aren't called if there's the submitted value is null.
That's why JSF components have a required attribute instead of a
standard JSF requiredValidator.
It's not possible to create a required validator without creating an
independent component-tree-scanning component that manually trigger
It seems like there's some overlap between this and weblets, with
weblets functionality being a subset of this concept.
https://weblets.dev.java.net/
http://java.sys-con.com/read/159161.htm
-
To unsubscribe, e-mail: [EMAIL PROTEC
On 12/28/05, Ryan Wynn <[EMAIL PROTECTED]> wrote:
> I have had success using most of the tomahawk components including
> tree2. The only tricky part is that some times the attribute names on
> the UIComponents are not the same as the attribute names on the jsp
> tag. In which case the tomahawk js
On 12/12/05, Hubert Rabago <[EMAIL PROTECTED]> wrote:
> Some of the code that's an integral part of Struts are in commons,
> such as BeanUtils and Chain. If the shared code is not
> tomahawk/myfaces specific, then this sounds like more reason to put
> this in a "commons"-type package. It sounds l
On 12/9/05, Martin Cooper <[EMAIL PROTECTED]> wrote:
> Let's say that Shale and MyFaces wanted to share some underpinning code,
> meaning that neither will run without it. Just for the sake of argument,
> let's pretend it's something like Commons Resources, but it lives at
> MyFaces. Now someone wh
ing up (Maven, zones) and then there's
> > the 1.2 spec. Plus on the Shale side we're trying to raise the
> > profile of that project and get some releases out the door.
> > Personally I'd rather see a few other things addressed like a "pet
> > sh
This has come up recently on the Myfaces-dev mailing list. We're
probably going to be splitting off a "jsf commons" package at some
point. Myfaces/share contains what would probably end up in such a
package.
Do a search for thread "[proposal] myfaces-core.jar" on the
myfaces-dev mailing list,
On 11/29/05, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> * CommonsValidator
>
> This is a JSF Validator, so it could well be attached to a UIComponent
> stored in session scope. It's not obvious from a static review of the code
> what's the problem, but if there is one it'll need to be fixed.
I
David Geary <[EMAIL PROTECTED]> wrote:
> I think this is all good stuff, but I'd rather see integration with
> Tiles instead of reinventing Tiles. Tiles has already covered some of
> this ground and I see no reason for us to follow.
I haven't used JSF enough to see if it fits the same pattern, b
Dakota Jack <[EMAIL PROTECTED]> wrote:
> Duncan Mills seems to characterize this as PrivateProcess. Something
> like that seems far more didactic and helpful to me than something it
> really is not, like Dialogue or Conversation. My suggestion is that
> the name reflect precisely what it is.
Per
Martin Cooper <[EMAIL PROTECTED]> wrote:
> Other issues with keeping Eclipse files in our repo:
>
> 1) The expectation would be that they would be kept up to date. If a
> particular committer doesn't use Eclipse, I don't think it's fair to
> expect them to keep Eclipse config files up to date when
Joe Germuska <[EMAIL PROTECTED]> wrote:
> > into an "action-chain" and "view-chain", but maybe it should be more
> > finely grained?
Hubert Rabago <[EMAIL PROTECTED]> wrote:
> The extreme case I have in mind would be one chain for each step that
> the current request processor does. Yes, I know,
Joe Germuska <[EMAIL PROTECTED]> wrote:
> My main question is how is the development community?
>From a user point of view, it's dead. Occasionally a bug fix might be
committed to cvs, but no new development is occurring. The last closed RFE
was April of 2003.
>From what I understand, what yo
Martin Cooper <[EMAIL PROTECTED]> wrote:
> For a very long time now, we have had a strict policy of not including
> anything that is not part of the HTML 4.01 spec or XHTML spec. I am
> still very much in favour of that policy, and am actively
> disinterested in seeing non-conforming additions to S
nt to
receive. In fact, we can just have all apache mailing lists go to one
address
-Mike
> - Original Message -
> From: "Mike Kienenberger" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> Sent: Wednesday, Oc
Richard Bywater <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Just wondering if there has been any consideration to creating new lists
to use for Wiki & Commit updates? (Or maybe just one "update" list)
>
> I know that I can filter these out in the email client but was thinking it
might be useful to be
Michael McGrady <[EMAIL PROTECTED]> wrote:
> Is there a way that it would make sense in the future to allow
> developers using Struts to specify their own interface for multipart
> request handlers? This is probably a stupid suggestion but couldn't
> Struts leave the interface at something like
Rick Reumann <[EMAIL PROTECTED]> wrote:
> Mike Kienenberger wrote the following on 9/17/2004 2:17 PM:
> > Any time you allow an end user an opportunity to specify a parameter for
> > reflection, you're introducing security concerns.
> > However, a "sec
Rick Reumann <[EMAIL PROTECTED]> wrote:
> Mike Kienenberger wrote the following on 9/17/2004 2:17 PM:
>
> > Not relevent to my situation. We require a WebObjects-like page state
cache
> > to handle backtracking issues. Thus our URLs end up looking like
>
Rick Reumann <[EMAIL PROTECTED]> wrote:
> *Without using Javascript to swap out the form Action name, I'm curious
> how you guys accomplish using multiple buttons for a form without the
> use of a DispatchAction?*
> You could of course submit to one regular Action that will look at the
> parame
It's also very easy to create your own custom DatabaseMessageResource class
following the methodology that James used.
Just create a trivial "DatabaseMessageResourcesFactory extends
PropertyMessageResourcesFactory" to point to your DatabaseMessageResource
class, then in your "DatabaseMessageReso
Martin Cooper <[EMAIL PROTECTED]> wrote:
> On Tue, 24 Aug 2004 22:47:01 -0400, Dave Brosius <[EMAIL PROTECTED]> wrote:
> > h.. I think i see why parking happens :)
>
> Please enlighten us. I'm missing the link between a request to follow
> our standard bug reporting process and "parking"...
B
I'm fairly certain that Struts 1.1 is pre-maven. Maven is only helpful for
CVS and struts 1.2.
-Mike
Hien Q Nguyen <[EMAIL PROTECTED]> wrote:
> Abhishek,
>
> Maven will attempt to download all the dependent jar files for you.
> You don't need to worry about adding any jar to classpath.
>
"Jung, Eric" <[EMAIL PROTECTED]> wrote:
> This probably has been asked before, but I did search the archives and
didn't come up with much.
>
> I'm wondering if I can replace Commons Collections 3.0 for of the version
of Commons Collections
> that shipped with Struts 1.1 and still expect Struts t
24 matches
Mail list logo
