Isn't there an EL builtin function for size/length though? I think
the following should work:
@Validate(expression="fn:length(this) > 0)")
or alternatively
@Validate(expression="!empty(this)")
My syntax/names might be a little off, but you get the idea.
-t
On Mar 29, 2008, at 4:54
Is this something you want to do globally? If so you might want to
just do it in a request wrapper that overrides getParameter() and
getParameterValues() to return trimmed versions.
-t
On Mar 31, 2008, at 12:11 PM, Alan Burlison wrote:
> Alan Burlison wrote:
>
>> I need to trim leading and
Alan,
I completely agree. I think adding @Validate(trim=[false|true])
would work well for most folks. Can you JIRA it please? Thanks,
-t
On Apr 1, 2008, at 9:53 AM, Alan Burlison wrote:
> Freddy D. wrote:
>
>> Alan, your best bet is likely to use a @Before
>> BindingAndValidation method
You know, the more I think about this, the more I think we've all
been barking up the wrong tree. When you have lists in your action
bean (or domain model) the validations are applied individually to
each element of the list as it gets bound. So the expression would
be evaluated against e
Not currently. You're right that you could do this with a custom
resolver. Depending on how many URLs you want, there's also another
cheap way to do it. If it's a fairly limited set of beans you want
to do this to, and a small number of alternative URLs you could
simple subclass the Acti
You're right. We should definitely add accessor for those attributes
- at least as protected and perhaps as public. Can you log a JIRA for
it please?
On a related note I'm fairly well aware that some of the localization
stuff in Stripes isn't as pluggable or as flexible as some folks
nee
Anywhere in your ActionBean code you can call:
StripesFilter.getConfiguration().getActionResolver()...
In fact this will work in pretty much any java code as long as the
StripesFilter is somewhere in the call stack.
-t
On Apr 3, 2008, at 7:54 PM, Chris Cheshire wrote:
> How do I get a referen
Thanks! I use this plugin all the time at work and it's very handy.
Looking forward to the next release.
-t
On Apr 3, 2008, at 11:18 PM, Evgeny Shepelyuk wrote:
> Hi guys !
> For everybody interested in IDEA plugin - i'm new developer of
> IntelliStripes.
> We're fixing some old bugs/impelm
#2.
-t
On Apr 4, 2008, at 9:23 AM, Gregg Bolinger wrote:
> So if I create a project and have this plugin installed do I have to
> specifically create a Stripes Project to get the benefits? Or can I
> create a project that uses Stripes and still get the plugin benefits?
>
> Thanks.
>
> Evgeny She
Lol! It's more likely that the plugin for developing eclipse plugins
doesn't work very well so noone has the patience to develop a stripes
plugin with it ;)
Let the flame wars begin!
-t
On Apr 7, 2008, at 3:43 PM, Ben Gunter wrote:
> Eclipse must be so awesome that we've never needed a Str
it... BTW,
> I'm former JBuilder IDE user...
>
> Please no flame wars here... waste of time and energy...
>
> regards,
> Ruslan
>
> ____________
>
> From: [EMAIL PROTECTED] on behalf of Tim
> Fennell
> Sent: Mon 4/7/2008 3:54 PM
&g
There isn't really a way to stop this. But you raise an interesting
point, for almost all types there is a sensible default value - and
Stripes uses that where appropriate. E.g. for ints it will set 0,
and for boolean it will set false. The problem is with Booleans that
you can make the
This could be because there is no constructor in FileBean that takes
just a single string. The constructors are:
public FileBean(File file, String contentType, String originalName);
public FileBean(File file, String contentType, String originalName,
String charset);
So now I guess the questi
This is actually fixed in 1.5. When I wrote the number type
converters orginally I didn't realize that the NumberFormat classes
in the JDK will suck a number off the front of a String and not
complain! Someone posted a bug with a better way to do this (using
NumberFormat and ParsePosition
Can anyone with Spring experience help George out? This doesn't look
(to me) like a Stripes specific problem, but then since I don't know a
whole lot about Spring it's hard to know!
-t
On Apr 16, 2008, at 1:49 PM, <[EMAIL PROTECTED]> wrote:
Hi all,
I am using Stripes 1.4.3, Spring 2.5.3
Hey Bob,
I'm sorry, I've not seen this error before. We actually use JBoss
4.0.2 at work so I quickly downloaded the distribution and threw the
stripes-examples.war into my servers's deploy directory. It deployed
fine and I can access all the example applications without any
exceptions.
The long and the short is that you should probably take a look at the
1.5 beta instead of 1.4.3. The way we scanned for classes in 1.4.3
was heavily dependent on finding a URLClassLoader to work with. The
code in 1.5 is much more friendly to other class loaders and should
work in a lot o
So, here's my question. Is there a way for Stripes to know the
DOCTYPE you are using without having you re-state it in some stripes
specific tag? I ask because of the two valid alternatives you give at
least one is invalid XHTML. I'm not completely up on this but aren't
there cases where
This, as the exception explains, happens when a request is filtered by
the StripesFilter but some code requires access to the Stripes
configuration. If you are navigating straight to a JSP and the JSP
contains Stripes tags, you must ensure that the request still goes
through the StripesFil
Bear with me a minute here Stripers. I was in a Borders book store
today killing a little time. I wandered over to the tech books
section to see what was new. A new O'Reilly book caught my eye called
"Harnessing Hibernate". It sounded like it'd be a real high-end
hibernate book and that
I've been thinking about the different error handling for different
methods for a while, but we haven't implemented anything for 1.5.
Essentially I think I'd like to go to a model where you can decorate
any method on the class with something like:
@HandlesErrors public fallback() { ...
jsp
>
> That's right, there's a quote from our favorite framework creator,
> Tim Fennell himself ;-)
>
> Cheers,
> Freddy
>
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all
I think you're best bet would be to write either your own
FloatTypeConverter or your own TypeConverterFactory.
The latter would probably be the easiest approach. In that case you
could probably just override and very simply add some logic to switch
the locale back to US regardless of what t
Well, that's because we never really thought anyone would want to set
locale on a page by page basis ;)
I think you can do what you want in an ActionBean with code something
like:
StripesRequestWrapper
.findStripesWrapper(getContext().getRequest()).setLocale(Locale.EN_US);
-t
On J
I think you have it. The JavaBean spec defines the relationship
between a "property name" and the accessor/mutator methods for that
property. In this case if you have a property called "name" then the
accessor methods would be called getName()/setName (unless name was a
boolean of course)
I think you have it. The JavaBean spec defines the relationship
between a "property name" and the accessor/mutator methods for that
property. In this case if you have a property called "name" then the
accessor methods would be called getName()/setName (unless name was a
boolean of course)
If you define a message in StripesResources.properties with the key:
package.actionClass.fieldName.errorMessage (if you're using Stripes
1.5)
or url.fieldName.errorMessage (if you're using Stripes 1.4)
then that message will be used in preference. Stripes will still
generate two
In Stripes 1.4 we used encryption keys that were specific to the
user's session. Starting with Stripes 1.5 we use (by default) a
single key for the application which will be able to decrypt values
across sessions (and if configured so, across restarts).
So the easiest solution is probably
Shawn:
I'm not sure what's going wrong. You're expectations about what
should happen are correct. Can you do one of two things please?
1) Package up a war file (with source) of the smallest possible test
case you can build that demonstrates the error?
2) Deploy the stripes examples applica
Do you have the URLRewrite filter mapped only to the REQUEST
dispatcher, or does it also kick in on INCLUDEs? It sounds to me
like the Stripes code is expected to only ever be called through an
include, and in this case is not because something is intercepting in
the middle and doing somet
The code that you have found comes from the LayoutDefinitionTag.
This tag should only ever occur on the page that defines the common
layout (not on pages using that layout). Because of this, certain
assumptions are made:
1) Layout JSPs (those using s:layout-definition) are only ever
exe
Awesome. Glad to hear you worked it out. Were there any error
messages along the way that could/should have been more helpful? If
so, please do log JIRAs for those as it's just as important to us that
Stripes provides helpful errors when things do go wrong.
-t
On Jul 3, 2008, at 2:41 AM
Hey Alan,
I'm not sure this is a bug. I'm not saying it isn't, I'm just not
sure it is either. You are supplying recordName to the message
right? If we escaped all the parameters to a message then you would
never be able to supply an HTML character in a message. If you
wanted to write
Ummm, so in the .zip file of the 15.RC1 release (and also will be
there in the final) is a file called upgrading.txt which lists out
all the major backwards compatibility issues. It doesn't list all
the changes in class/method APIs that are public, but it hits all the
changes that most use
This hasn't really changed since 1.4.x as far as I know. We've never
instantiated the action bean on the JSP if it wasn't there. There
are a number of ways to get around this:
1) use a s:useActionBean tag on the JSP
2) have your index.jsp just issue a jsp:forward to the actionBean and
then
So I have to admit that I'm kinda with Remi on this one :o I
understand that there are folks out there who want this capability.
But for me the light bulb has not gone off - I don't get why you
would want to do this deep-down, very close to the protocol, REST stuff.
Of course, if Will or s
ng to defend this now because I don't think
there is any need to, just as there is no need to bash it either.
On Wed, Jul 9, 2008 at 10:48 AM, Tim Fennell <[EMAIL PROTECTED]>
wrote:
So I have to admit that I'm kinda with Remi on this one :o I
understand that there are folks o
Returning a 30K table as an HTML table in one single request will
actually have pretty poor rendering time in the browser. Some
browsers (I don't know about IE) will not render a table until they
hit the tag so that they don't have to re-flow it. We have
some pages at work that show 3-5K
That seems reasonable to me. Could you open a JIRA for it please?
-t
On Jul 18, 2008, at 6:02 PM, Karol Kisielewski wrote:
> Newman, John W pisze:
>> Could we add an anchor attribute to the tag? That should be a
>> pretty
>> trivial patch, and I know I’ve wanted this a few times this before
Stripes does indeed store things in a HashMap (ValidationErrors is
actually a sublcass of HashMap). The s:errors tag also drops all the
errors into a set so that we can't display the exact same text twice
(which can happen when using indexed properties and you get the same
error on differe
Automatically no. Have we started the process, yes ;)
You can follow the ticket here if you're interested:
http://jira.codehaus.org/browse/MAVENUPLOAD-2179
-t
On Aug 18, 2008, at 1:01 PM, David G Friedman wrote:
Ben,
Does the release automatically push out to maven repositories?
Re
Just to let everyone know, Ben submitted the release announcement to
the serverside and it's been published here:
http://www.theserverside.com/news/thread.tss?thread_id=50391
-t
On Aug 18, 2008, at 2:25 PM, Levi Hoogenberg wrote:
Great! It will be hard for 1.6 to trump this release in
Just to add a little more to this thread (sorry, I haven't been
reading my list mail for a few days, too much going on). I think
Gregg got my position only half right ;) My view on this kinda stuff
is pretty straightforward:
- True invariants should be expressed in the domain model. Stuff
Hmm, I don't know. It was created the exact same way as the last
bundle we submitted, so I'd hope it's ok. But I'm a complete maven
neophyte :o
-t
On Aug 19, 2008, at 10:30 AM, marijan milicevic wrote:
Tim Fennell wrote:
Automatically no. Have we started the proc
You almost certainly want to implement a custom ActionResolver. To
do this take a look at NameBasedActionResolver which is the default
one in Stripes - you'll probably want to extend this.
-t
On Aug 30, 2008, at 7:50 PM, Nathan Maves wrote:
> I am not sure which class I need to extend to ge
This is almost exactly how it works now, with one slight twist.
You've shown the idea that if you don't supply a label the value
should be used as the label - and it's implemented the other way
around. If no value is specified, the label is used as the value.
The label in turn is looked f
Stripes creates objects on the fly during binding, but won't
instantiate objects on the fly when it's just trying to read
information. From Stripes' perspective you've asked to display
"person.name" but person is null - why would Stripes make up a person
and then try to display their name?
It's really quite simple. What happens during a regular form
submission is that the browser includes a parameter based on the
button that was clicked. So if you have a button that looks like this
in HTML:
then when you click on it the browser will add the following to the
set o
I wonder could it be anything to do with your Locale settings? It
seems like Currency.getInstance() is exploding deep within the
NumberTypeConverterSupport class. That's a pretty innocuous call and
a bogus locale is the only thing I can think of that might cause
that
-t
On Sep 30, 2
; I would think it would then use this locale if I understood the
> TypeConverter(s) correct?
> Maybe da_DA (Danish) is not supported?
>
>
> Tim Fennell-3 wrote:
>>
>> I wonder could it be anything to do with your Locale settings? It
>> seems like Currency.getInsta
I can't see anything immediately wrong with the web.xml you have
there. A few questions:
- Does the exact same war file deploy and work fine on your
development machine?
- What's different about the production machine? Is it the same JVM
version, same Tomcat version
-t
On Oct 2, 2008, a
So, actually this works reasonably well already in 1.5, will work
better in 1.5.1 and beyond that the only problem is actually with
related technologies.
When I say works, I mean you should be able to just have:
public Date birthday;
and Stripes will work with the public property inst
I haven't looked closely at the field-metadata tag, but the Stripes
form/input tags in general will work across includes and tag file
invocations. The way they do this is by maintaining a tag-stack in
the request object. When a tag wishes to find it's parent it performs
both the usual JSP
Does changing the TLD fix the problem? If it does, it sounds to me
like a minor bug that we should just fix in the TLD and be done with.
-t
On Dec 9, 2008, at 11:50 AM, phil darley wrote:
> Hi,
>
> I'm attempting to get stripes to run on a 1.4 jee application server,
> specifically Weblogic 8.
You probably also want to call:
return new StreamingResolution("audio/mp3", Object>).setFilename("foo.mp3");
That last part will cause Stripes to send the appropriate headers to
the browser that informs it that the stream of data it's about to
receive should be treated as a file as opposed
I think when this is complete it may be worthwhile updating the
> Stripes 1.4 info page explaining the workaround for servlet containers
> which don't support JSP spec 2.0.
>
> Cheers,
> Phil
>
> On Tue, Dec 9, 2008 at 5:47 PM, Tim Fennell wrote:
>> Does changing the TLD f
I sorta agree with Oscar, except that I think I'd implement it as a
Stripes Interceptor that wraps around ActionBeanResolution. That way
the Interceptor would know the ActionBean being targeting and could
use that information to "adjust" the request parameters.
-t
On Jan 6, 2009, at 3:59 P
I think I see what's going on here John. FYI, I'm cc'ing the users
list in case I'm wrong in which case others can chime in and help.
Stripes input tags live within the context of a stripes form. When
they attempt to pre-populate or re-populate their values they look for
an ActionBean of
Hi Wade,
The problem is because you're using indexed properties. When you have
property names like 'names[0]' Stripes does validation a little
differently. It assumes each index (e.g. 0) is a "row" in a form and
only applies validation if at least one value in a row is entered.
The easy
Is there a reason that you can't do something like (syntax may be
slightly off):
-t
On Feb 19, 2009, at 5:26 AM, Richard Hauswald wrote:
> Hello,
> i want to send a redirect to a stripes action bean inside a jsp page
> referencing the bean by its class name, not the url. I lo
60 matches
Mail list logo
