Pat Lightbody wrote:
I don't think is yet supported by Ognl. The Ognl mailing list has been VERY
quiet lately... it's starting to worry me a bit...
Drew? You still around? Need any help? :)
I'm alive :-)
I had to take a job a while back. Contracts were getting few and far
between. I guess O
If I understand your scenario then the error occurs when BeanUtil is copying
properties from the AddressAction to the UserAction.
Check that you do not have methods with the same name but with different/incompatible
types on the AddressAction and UserAction. Perhaps that could cause the
ClassCas
Hi guys,
In order to facilitate changing the UI tag templates, I suggest we split up
controlheader. A tag will be rendered using:
- include row-header
- include label-header
- include label
- include label-footer
- include widget-header
- include widget
- include widget-footer
- include row-foote
Hi
I apologise in advance if this is something obvious that I've missed in the docs, I
have searched the wiki and the mailing list archives for it but I didn't find
anything. I'll try and explain this as best I can so please bear with me.
Since I have User objects and a UserAction class I'm goin
Put simply : the tags are using the .toString method of the property instead
of the registered type converters.
This happens when you do a :
$tag.ActualValue .. This is an instance of an object, that velocity calls
toString() on to print it out.
I guess that I am saying that I want a new method
Is there any reason why Ognl is prefer over jstl el ? Thought it might be
better to go with the standard approach.
--- Pat Lightbody <[EMAIL PROTECTED]> wrote:
> I don't think is yet supported by Ognl. The Ognl mailing list has been VERY
> quiet lately... it's starting to worry me a bit...
>
> Dr
Well, we could check all super classes up until
Object-conversion.properties, but the real problem is that we have yet to
come up with a good game plan for how type conversion should be handled.
I've heard lots of small suggestions, but what we really need is a list of
problems with the current imp
I don't think is yet supported by Ognl. The Ognl mailing list has been VERY
quiet lately... it's starting to worry me a bit...
Drew? You still around? Need any help? :)
-Pat
- Original Message -
From: "Jason Carreira" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 29, 20
Odd, this should already be done, if not it's a bug. Can you open an issue?
-Pat
- Original Message -
From: "Cameron Braid" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 29, 2003 7:50 PM
Subject: [OS-webwork] WebWOrk2 Jsp Tag library
> Can the webwork 2 tld be changed
Actually, I'm not entirely following what you are doing, but I recently
added support so that you could have a file called
SomeObject-conversion.properties and then allow for a mapping between
propertyName and Ognl TypeConverter. Is that what you want?
-Pat
- Original Message -
From: "Cam
Title: Message
I have implemented my own type
converters for my custom types to convert to and from
string.
These converters work perfectly
when the Params Interceptor sets their values onto my
actions.
When I am using a custom UI
input... either through a custom JSP tag that extends Ab
Title: Message
Can the webwork 2 tld be
changed to allow all UI tags to have bodycontent JSP instead of empty to allow
usage of the param tag.
Currently I am using a modified
version of the templates/xhtml templates using custom parameters to modify the
behavior, and I have changed my vers
Title: Re: [OS-webwork] Suggestion for a change in UI Component Tag
Why would you want to do that? All WW tags should be AbstractWrappingTags (as they are now) - because they can all take parameters via the param tag?
Mike
On 29/5/03 7:28 PM, "Cameron Braid" ([EMAIL PROTECTED]) penned the word
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WW-201
Here is an overview of the issue:
-
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-51
Here is an overview of the issue:
--
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WW-200
Here is an overview of the issue:
-
Try having indexed getters and setters, like so:
public Kardon getKardon(int index)
public void setKardon(int index, Kardon kardon)
This might allow you to to use the index notation (not making any
promises :-))
Jason
> -Original Message-
> From: Buorn, Yoway [mailto:[EMAIL PROTECTED]
Message:
A new issue has been created in JIRA.
-
View the issue:
http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WW-199
Here is an overview of the issue:
-
Go ahead and post an issue in Jira on this. I'm finishing up some other
changes to the velocity tags, so I'll get to this as soon as I'm done
with what I'm currently working on
M
Fernando Martins wrote:
Is there any JIRA issue on this, or should it be created to that people
interested in this
It should be created as a Jira issue
> -Original Message-
> From: Fernando Martins [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 29, 2003 11:54 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [OS-webwork] shouldn't VelocityResult set
> charset in content-type?
>
>
>
>
> Is there any JIRA
Hi. I'm having a little trouble posting an array of objects to an Action. I have
container class that contains a few Vectors of other container classes, like so:
public class Harman
{
private Vector kardons;
// Omit getters and setters for brevity
This is an interesting question. The intent behind the component tag
was for it to behave like the other tags in that if you specified a
relative location, it would be relative to the root of the theme, and an
absolute location would be used untranslated.
So
would be looked for, current
Is there any JIRA issue on this, or should it be created to that people
interested in this issue could be notified when something will be
added/fixed.
Are you planning to do some work on this issue or could I propose some
code changes to support the webwork.i18n.encoding / velocity encoding ?
O
taa
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Matt Ho
> Sent: Friday, 30 May 2003 1:38 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [OS-webwork] Suggestion for a change in UI Component Tag
>
>
> Cameron Braid wrote:
> > on second thoughts..
Hello,
See below ...
Cameron Braid wrote:
Oh.. another thing.. is it possible to find templates that are specified
using a relative path, relative to the jsp that uses them ?
i.e.
/WEB-INF/views/test.jsp
/WEB-INF/views/test.vm
hello from test.vm
Can this work, allowing both test.js
I agree with Scott on this, I think the i18n stuff should be in the
webwork.properties file. However, I also think the ww2 should also
support an optional velocity properties.
M
Fernando Martins wrote:
On Thu, 29 May 2003, Scott Farquhar wrote:
Fernando,
IMHO the encoding in webwork should
Cameron Braid wrote:
> on second thoughts.. there was something confusing happening.. the TLD
> for the component tag declares that its contents MUST be empty :(
>
> Please change it to JSP and all is well :)
All is well :)
M
---
This SF.net e
You could set your theme to be /WEB-INF
M
Cameron Braid wrote:
Can the webwork velocity resource loader also include the WEB-INF folder
of the web application in the resource loader search path to enable
custom themes/templates to reside in WEB-INF without having to prefix
the theme name with
28 matches
Mail list logo