You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Colin Chalmers <Co...@xs4all.nl> on 2003/09/26 12:36:22 UTC
Intake Patch for 2.3.1 Branch
This patch fixes the problem identified by Scott whereby the correct
date format was not being shown on screen, instead a toString Dump of
the Date Object was being shown. In order to use the patch you should
change the reference to the value in Template from
$group.foo.Value
to
$group.foo.StringValue
which will then show the correctly formatted date. This can (but doesn't
have to) be used for all Values and not just Dates.
Can someone check this in? Scott let me know if this solves the problem.
Colin
Index: Field.java
===================================================================
RCS file:
/home/cvspublic/jakarta-turbine-2/src/java/org/apache/turbine/services/intake/model/Field.java,v
retrieving revision 1.15.2.1
diff -u -r1.15.2.1 Field.java
--- Field.java 26 Sep 2003 00:35:38 -0000 1.15.2.1
+++ Field.java 26 Sep 2003 10:26:15 -0000
@@ -996,4 +996,18 @@
return (StringUtils.isEmpty(maxSize) ? "" : maxSize);
}
+ /**
+ * Gets the String representation of the Value. This is basically a
wrapper
+ * method for the toString method which doesn't seem to show
anything on
+ * screen if accessed from Template. Name is also more in line with
getValue
+ * method which returns the actual Object.
+ * This is useful for displaying correctly formatted data such as
dates,
+ * such as 18/11/1968 instead of the toString dump of a Date Object.
+ *
+ * @return the String Value
+ */
+ public String getStringValue()
+ {
+ return this.toString();
+ }
}
Index: DateStringField.java
===================================================================
RCS file:
/home/cvspublic/jakarta-turbine-2/src/java/org/apache/turbine/services/intake/model/DateStringField.java,v
retrieving revision 1.9
diff -u -r1.9 DateStringField.java
--- DateStringField.java 18 Jul 2003 08:32:30 -0000 1.9
+++ DateStringField.java 26 Sep 2003 10:27:10 -0000
@@ -93,12 +93,6 @@
throws IntakeException
{
super(field, group);
-
- if (validator == null || !(validator instanceof
DateStringValidator))
- {
- df = DateFormat.getInstance();
- df.setLenient(true);
- }
}
/**
@@ -226,31 +220,4 @@
return date;
}
- /**
- * returns a String representation
- *
- * @return a String representation
- */
- public String toString()
- {
- String s = null;
- Object value = getValue();
- if (value == null)
- {
- s = "";
- }
- else if (value instanceof String)
- {
- s = (String) value;
- }
- else if (validator != null && validator instanceof
DateStringValidator)
- {
- s = ((DateStringValidator) validator).format((Date) value);
- }
- else
- {
- s = df.format((Date) value);
- }
- return s;
- }
}
RE: Updating Website Docs for 2.4..?
Posted by Eric Pugh <ep...@upstate.com>.
So,
I just updated the jakarta-turbine-site/xdocs/navigation.xml file so now I
can just build the site and upload away? Or does anything automagically
upload the site?
I just am being cautious as I don't want to mess up the public face of
Turbine!
Eric
> -----Original Message-----
> From: Scott Eade [mailto:seade@backstagetech.com.au]
> Sent: Tuesday, September 30, 2003 12:10 PM
> To: Turbine Developers List
> Subject: Re: Updating Website Docs for 2.4..?
>
>
> Eric Pugh wrote:
>
> >I wanted to toss out updating the
> >http://jakarta.apache.org/turbine/index.html page to also
> have a link to
> >turbine 2.4 development info which would go in
> >http://jakarta.apache.org/turbine/turbine-2.4/index.html...
> How is the main
> >index.html page maintained? By hand? Is it an xdoc someplace?
> >
> >I want to highlight the maven plugin for turbine, as well as
> other changes
> >for 2.4...
> >
> >
> I think you want jakarta-turbine-site
>
> Scott
>
> --
> Scott Eade
> Backstage Technologies Pty. Ltd.
> http://www.backstagetech.com.au
> seade@backstagetech.com.au
> Mobile: +61 403 278 908
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: Updating Website Docs for 2.4..?
Posted by Eric Pugh <ep...@upstate.com>.
So,
I just updated the jakarta-turbine-site/xdocs/navigation.xml file so now I
can just build the site and upload away? Or does anything automagically
upload the site?
I just am being cautious as I don't want to mess up the public face of
Turbine!
Eric
> -----Original Message-----
> From: Scott Eade [mailto:seade@backstagetech.com.au]
> Sent: Tuesday, September 30, 2003 12:10 PM
> To: Turbine Developers List
> Subject: Re: Updating Website Docs for 2.4..?
>
>
> Eric Pugh wrote:
>
> >I wanted to toss out updating the
> >http://jakarta.apache.org/turbine/index.html page to also
> have a link to
> >turbine 2.4 development info which would go in
> >http://jakarta.apache.org/turbine/turbine-2.4/index.html...
> How is the main
> >index.html page maintained? By hand? Is it an xdoc someplace?
> >
> >I want to highlight the maven plugin for turbine, as well as
> other changes
> >for 2.4...
> >
> >
> I think you want jakarta-turbine-site
>
> Scott
>
> --
> Scott Eade
> Backstage Technologies Pty. Ltd.
> http://www.backstagetech.com.au
> seade@backstagetech.com.au
> Mobile: +61 403 278 908
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Problem with 2.4 maven site? Javadoc fails
Posted by Eric Pugh <ep...@upstate.com>.
Hi all,
I am getting (with CVS head) an error on the javadoc task:
BUILD FAILED
File...... file:/c:/java/maven/plugins/maven-javadoc-plugin-1.3-SNAPSHOT/
Element... ant:javadoc
Line...... 108
Column.... 60
Javadoc failed: java.io.IOException: CreateProcess:
C:\java\j2sdk1.4.1_02\bin\ja
vadoc.exe -use -stylesheetfile
C:\java\maven\plugins\maven-javadoc-plugin-1.3-SN
APSHOT\plugin-resources\stylesheet.css -d
C:\java\jakarta-turbine-2\target\docs\
apidocs -windowtitle "jakarta-turbine-2 2.4-dev API" -doctitle
"jakarta-turbine-
2 2.4-dev API" -bottom "Copyright © 2000-2003 Apache Software
Foundation. A
ll Rights Reserved." -classpath
C:\java\maven\repository\avalon-framework\jars\a
valon-framework-4.1.4.jar;C:\java\maven\repository\commons-beanutils\jars\co
mmon
s-beanutils-1.6.1.jar;C:\java\maven\repository\commons-codec\jars\commons-co
dec-
1.1.jar;C:\java\maven\repository\commons-collections\jars\commons-collection
s-2.
1.jar;C:\java\maven\repository\commons-configuration\jars\commons-configurat
ion-
20030706.202021.jar;C:\java\maven\repository\commons-digester\jars\commons-d
iges
ter-1.5.jar;C:\java\maven\repository\commons-email\jars\commons-email-200303
10.1
65926.jar;C:\java\maven\repository\commons-fileupload\jars\commons-fileuploa
d-1.
0.jar;C:\java\maven\r?
Total time: 1 minutes 8 seconds
Finished at: Tue Sep 30 13:54:16 CEST 2003
Anyone else getting this? Other apps work fine..
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Problem with 2.4 maven site? Javadoc fails
Posted by Eric Pugh <ep...@upstate.com>.
Hi all,
I am getting (with CVS head) an error on the javadoc task:
BUILD FAILED
File...... file:/c:/java/maven/plugins/maven-javadoc-plugin-1.3-SNAPSHOT/
Element... ant:javadoc
Line...... 108
Column.... 60
Javadoc failed: java.io.IOException: CreateProcess:
C:\java\j2sdk1.4.1_02\bin\ja
vadoc.exe -use -stylesheetfile
C:\java\maven\plugins\maven-javadoc-plugin-1.3-SN
APSHOT\plugin-resources\stylesheet.css -d
C:\java\jakarta-turbine-2\target\docs\
apidocs -windowtitle "jakarta-turbine-2 2.4-dev API" -doctitle
"jakarta-turbine-
2 2.4-dev API" -bottom "Copyright © 2000-2003 Apache Software
Foundation. A
ll Rights Reserved." -classpath
C:\java\maven\repository\avalon-framework\jars\a
valon-framework-4.1.4.jar;C:\java\maven\repository\commons-beanutils\jars\co
mmon
s-beanutils-1.6.1.jar;C:\java\maven\repository\commons-codec\jars\commons-co
dec-
1.1.jar;C:\java\maven\repository\commons-collections\jars\commons-collection
s-2.
1.jar;C:\java\maven\repository\commons-configuration\jars\commons-configurat
ion-
20030706.202021.jar;C:\java\maven\repository\commons-digester\jars\commons-d
iges
ter-1.5.jar;C:\java\maven\repository\commons-email\jars\commons-email-200303
10.1
65926.jar;C:\java\maven\repository\commons-fileupload\jars\commons-fileuploa
d-1.
0.jar;C:\java\maven\r?
Total time: 1 minutes 8 seconds
Finished at: Tue Sep 30 13:54:16 CEST 2003
Anyone else getting this? Other apps work fine..
Eric
Re: Updating Website Docs for 2.4..?
Posted by Scott Eade <se...@backstagetech.com.au>.
Eric Pugh wrote:
>I wanted to toss out updating the
>http://jakarta.apache.org/turbine/index.html page to also have a link to
>turbine 2.4 development info which would go in
>http://jakarta.apache.org/turbine/turbine-2.4/index.html... How is the main
>index.html page maintained? By hand? Is it an xdoc someplace?
>
>I want to highlight the maven plugin for turbine, as well as other changes
>for 2.4...
>
>
I think you want jakarta-turbine-site
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
seade@backstagetech.com.au
Mobile: +61 403 278 908
Re: Updating Website Docs for 2.4..?
Posted by Scott Eade <se...@backstagetech.com.au>.
Eric Pugh wrote:
>I wanted to toss out updating the
>http://jakarta.apache.org/turbine/index.html page to also have a link to
>turbine 2.4 development info which would go in
>http://jakarta.apache.org/turbine/turbine-2.4/index.html... How is the main
>index.html page maintained? By hand? Is it an xdoc someplace?
>
>I want to highlight the maven plugin for turbine, as well as other changes
>for 2.4...
>
>
I think you want jakarta-turbine-site
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
seade@backstagetech.com.au
Mobile: +61 403 278 908
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Updating Website Docs for 2.4..?
Posted by Eric Pugh <ep...@upstate.com>.
Hi all,
I wanted to toss out updating the
http://jakarta.apache.org/turbine/index.html page to also have a link to
turbine 2.4 development info which would go in
http://jakarta.apache.org/turbine/turbine-2.4/index.html... How is the main
index.html page maintained? By hand? Is it an xdoc someplace?
I want to highlight the maven plugin for turbine, as well as other changes
for 2.4...
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Updating Website Docs for 2.4..?
Posted by Eric Pugh <ep...@upstate.com>.
Hi all,
I wanted to toss out updating the
http://jakarta.apache.org/turbine/index.html page to also have a link to
turbine 2.4 development info which would go in
http://jakarta.apache.org/turbine/turbine-2.4/index.html... How is the main
index.html page maintained? By hand? Is it an xdoc someplace?
I want to highlight the maven plugin for turbine, as well as other changes
for 2.4...
Eric
Re: Intake Patch for 2.3.1 Branch
Posted by Colin Chalmers <Co...@xs4all.nl>.
Yes, localized to the current user :-) If you were to support multiple
locations simultaneously then there would need to be a way of providing
a set of formats for each locale that is supported. It is already a
pain that the same format rules are going to be specified for every date
that is presented via intake - we need to be able to define rulesets to
apply to fields to get over this.
I meant getting the locale from the session and setting the correct
format that way, could also be implemented for numbers, I think it's
already done for BigDecimal.
I'm a bit concerned that the Intake get's (mis)used for more than just
(Intake) validation; ie formatting and displaying info. OR at least
having to define formats disply in (at least) two places.
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Intake Patch for 2.3.1 Branch
Posted by Colin Chalmers <Co...@xs4all.nl>.
Yes, localized to the current user :-) If you were to support multiple
locations simultaneously then there would need to be a way of providing
a set of formats for each locale that is supported. It is already a
pain that the same format rules are going to be specified for every date
that is presented via intake - we need to be able to define rulesets to
apply to fields to get over this.
I meant getting the locale from the session and setting the correct
format that way, could also be implemented for numbers, I think it's
already done for BigDecimal.
I'm a bit concerned that the Intake get's (mis)used for more than just
(Intake) validation; ie formatting and displaying info. OR at least
having to define formats disply in (at least) two places.
Colin
RE: Intake Patch for 2.3.1 Branch
Posted by Eric Pugh <ep...@upstate.com>.
Great.. I agree with the PITA aspect.. But, I guess the only way to move
forward is to only apply bug fixes to all three, and any enhancements only
go in the fulcrum branch.. So, if you are technically applying
enhancements, then you can just apply them there...
After all, when 2.4 comes out, you should be using the fulcrum components
throughout!
The only roadblock on using fulcrum intake right now is that I think the
intake tool should be either part of turbine, or part of a fulcrum-turbine
collection of turbine components..
Eric
> -----Original Message-----
> From: Scott Eade [mailto:seade@backstagetech.com.au]
> Sent: Monday, September 29, 2003 3:37 PM
> To: Turbine Developers List
> Subject: Re: Intake Patch for 2.3.1 Branch
>
>
> Eric Pugh wrote:
>
> >Are you going to apply the patch to the Fulcrum version as
> well? I'm not
> >sure what the patching rules are, but it seems like if we
> can finish getting
> >intake deprecated in 2.4, then we can only patch in 2.3.1
> and in intake,
> >correct?
> >
> >
> Would still need to patch 2.4 since it will in theory only be
> deprecated
> in 2.4.
>
> Having to make changes in 2 places is a PITA. Having to make it in 3
> places will I am sure be really great fun :-(
>
> I'll look into porting my patches over once I am happy things have
> reached a stable point.
>
> Scott
>
> --
> Scott Eade
> Backstage Technologies Pty. Ltd.
> http://www.backstagetech.com.au
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: Intake Patch for 2.3.1 Branch
Posted by Eric Pugh <ep...@upstate.com>.
Great.. I agree with the PITA aspect.. But, I guess the only way to move
forward is to only apply bug fixes to all three, and any enhancements only
go in the fulcrum branch.. So, if you are technically applying
enhancements, then you can just apply them there...
After all, when 2.4 comes out, you should be using the fulcrum components
throughout!
The only roadblock on using fulcrum intake right now is that I think the
intake tool should be either part of turbine, or part of a fulcrum-turbine
collection of turbine components..
Eric
> -----Original Message-----
> From: Scott Eade [mailto:seade@backstagetech.com.au]
> Sent: Monday, September 29, 2003 3:37 PM
> To: Turbine Developers List
> Subject: Re: Intake Patch for 2.3.1 Branch
>
>
> Eric Pugh wrote:
>
> >Are you going to apply the patch to the Fulcrum version as
> well? I'm not
> >sure what the patching rules are, but it seems like if we
> can finish getting
> >intake deprecated in 2.4, then we can only patch in 2.3.1
> and in intake,
> >correct?
> >
> >
> Would still need to patch 2.4 since it will in theory only be
> deprecated
> in 2.4.
>
> Having to make changes in 2 places is a PITA. Having to make it in 3
> places will I am sure be really great fun :-(
>
> I'll look into porting my patches over once I am happy things have
> reached a stable point.
>
> Scott
>
> --
> Scott Eade
> Backstage Technologies Pty. Ltd.
> http://www.backstagetech.com.au
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Intake Patch for 2.3.1 Branch
Posted by Scott Eade <se...@backstagetech.com.au>.
Eric Pugh wrote:
>Are you going to apply the patch to the Fulcrum version as well? I'm not
>sure what the patching rules are, but it seems like if we can finish getting
>intake deprecated in 2.4, then we can only patch in 2.3.1 and in intake,
>correct?
>
>
Would still need to patch 2.4 since it will in theory only be deprecated
in 2.4.
Having to make changes in 2 places is a PITA. Having to make it in 3
places will I am sure be really great fun :-(
I'll look into porting my patches over once I am happy things have
reached a stable point.
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
Re: Intake Patch for 2.3.1 Branch
Posted by Scott Eade <se...@backstagetech.com.au>.
Eric Pugh wrote:
>Are you going to apply the patch to the Fulcrum version as well? I'm not
>sure what the patching rules are, but it seems like if we can finish getting
>intake deprecated in 2.4, then we can only patch in 2.3.1 and in intake,
>correct?
>
>
Would still need to patch 2.4 since it will in theory only be deprecated
in 2.4.
Having to make changes in 2 places is a PITA. Having to make it in 3
places will I am sure be really great fun :-(
I'll look into porting my patches over once I am happy things have
reached a stable point.
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: Intake Patch for 2.3.1 Branch
Posted by Eric Pugh <ep...@upstate.com>.
Scott,
Are you going to apply the patch to the Fulcrum version as well? I'm not
sure what the patching rules are, but it seems like if we can finish getting
intake deprecated in 2.4, then we can only patch in 2.3.1 and in intake,
correct?
Eric
> -----Original Message-----
> From: Scott Eade [mailto:seade@backstagetech.com.au]
> Sent: Monday, September 29, 2003 8:24 AM
> To: Turbine Developers List
> Subject: Re: Intake Patch for 2.3.1 Branch
>
>
> Colin Chalmers wrote:
>
> > I removed the toString in the DateString because I found
> the code to
> > be redundant since it was basically performing an action that had
> > already been done; ie converting the Date Object to a String
> > (stringValue). This value is also returned using the
> Field.toString()
> > method. So I found the overriding method to be duplicate code.
>
> It definitely doesn't work without the DateString.toString() method -
> without it data read from the database is not formatted in
> the desired
> manner.
>
> > This is also what I meant with trying to simplify the IntakeCode. I
> > feel there are too many variables with similiar names
> without a clear
> > distinction as to what they actually do and a couple of
> methods which
> > seem to duplicate code, all by all making the Intake code more
> > complicated than necessary.
>
> Tell me about it - there is stuff in there that just isn't
> used. I just
> applied a further patch to get the emptyValue attributes to work.
>
> > On a side note, the date is presented using the first format in the
> > available acceptable formats, would it not be better to
> display using
> > localized format?
>
> Yes, localized to the current user :-) If you were to
> support multiple
> locations simultaneously then there would need to be a way of
> providing
> a set of formats for each locale that is supported. It is already a
> pain that the same format rules are going to be specified for
> every date
> that is presented via intake - we need to be able to define
> rulesets to
> apply to fields to get over this.
>
> I posted a link earlier today to a wiki - Quinton put a bunch
> of intake
> wish-list items up there some time ago.
>
> Cheers,
>
> Scott
>
> --
> Scott Eade
> Backstage Technologies Pty. Ltd.
> http://www.backstagetech.com.au
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: Intake Patch for 2.3.1 Branch
Posted by Eric Pugh <ep...@upstate.com>.
Scott,
Are you going to apply the patch to the Fulcrum version as well? I'm not
sure what the patching rules are, but it seems like if we can finish getting
intake deprecated in 2.4, then we can only patch in 2.3.1 and in intake,
correct?
Eric
> -----Original Message-----
> From: Scott Eade [mailto:seade@backstagetech.com.au]
> Sent: Monday, September 29, 2003 8:24 AM
> To: Turbine Developers List
> Subject: Re: Intake Patch for 2.3.1 Branch
>
>
> Colin Chalmers wrote:
>
> > I removed the toString in the DateString because I found
> the code to
> > be redundant since it was basically performing an action that had
> > already been done; ie converting the Date Object to a String
> > (stringValue). This value is also returned using the
> Field.toString()
> > method. So I found the overriding method to be duplicate code.
>
> It definitely doesn't work without the DateString.toString() method -
> without it data read from the database is not formatted in
> the desired
> manner.
>
> > This is also what I meant with trying to simplify the IntakeCode. I
> > feel there are too many variables with similiar names
> without a clear
> > distinction as to what they actually do and a couple of
> methods which
> > seem to duplicate code, all by all making the Intake code more
> > complicated than necessary.
>
> Tell me about it - there is stuff in there that just isn't
> used. I just
> applied a further patch to get the emptyValue attributes to work.
>
> > On a side note, the date is presented using the first format in the
> > available acceptable formats, would it not be better to
> display using
> > localized format?
>
> Yes, localized to the current user :-) If you were to
> support multiple
> locations simultaneously then there would need to be a way of
> providing
> a set of formats for each locale that is supported. It is already a
> pain that the same format rules are going to be specified for
> every date
> that is presented via intake - we need to be able to define
> rulesets to
> apply to fields to get over this.
>
> I posted a link earlier today to a wiki - Quinton put a bunch
> of intake
> wish-list items up there some time ago.
>
> Cheers,
>
> Scott
>
> --
> Scott Eade
> Backstage Technologies Pty. Ltd.
> http://www.backstagetech.com.au
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Intake Patch for 2.3.1 Branch
Posted by Scott Eade <se...@backstagetech.com.au>.
Colin Chalmers wrote:
> I removed the toString in the DateString because I found the code to
> be redundant since it was basically performing an action that had
> already been done; ie converting the Date Object to a String
> (stringValue). This value is also returned using the Field.toString()
> method. So I found the overriding method to be duplicate code.
It definitely doesn't work without the DateString.toString() method -
without it data read from the database is not formatted in the desired
manner.
> This is also what I meant with trying to simplify the IntakeCode. I
> feel there are too many variables with similiar names without a clear
> distinction as to what they actually do and a couple of methods which
> seem to duplicate code, all by all making the Intake code more
> complicated than necessary.
Tell me about it - there is stuff in there that just isn't used. I just
applied a further patch to get the emptyValue attributes to work.
> On a side note, the date is presented using the first format in the
> available acceptable formats, would it not be better to display using
> localized format?
Yes, localized to the current user :-) If you were to support multiple
locations simultaneously then there would need to be a way of providing
a set of formats for each locale that is supported. It is already a
pain that the same format rules are going to be specified for every date
that is presented via intake - we need to be able to define rulesets to
apply to fields to get over this.
I posted a link earlier today to a wiki - Quinton put a bunch of intake
wish-list items up there some time ago.
Cheers,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Intake Patch for 2.3.1 Branch
Posted by Scott Eade <se...@backstagetech.com.au>.
Colin Chalmers wrote:
> I removed the toString in the DateString because I found the code to
> be redundant since it was basically performing an action that had
> already been done; ie converting the Date Object to a String
> (stringValue). This value is also returned using the Field.toString()
> method. So I found the overriding method to be duplicate code.
It definitely doesn't work without the DateString.toString() method -
without it data read from the database is not formatted in the desired
manner.
> This is also what I meant with trying to simplify the IntakeCode. I
> feel there are too many variables with similiar names without a clear
> distinction as to what they actually do and a couple of methods which
> seem to duplicate code, all by all making the Intake code more
> complicated than necessary.
Tell me about it - there is stuff in there that just isn't used. I just
applied a further patch to get the emptyValue attributes to work.
> On a side note, the date is presented using the first format in the
> available acceptable formats, would it not be better to display using
> localized format?
Yes, localized to the current user :-) If you were to support multiple
locations simultaneously then there would need to be a way of providing
a set of formats for each locale that is supported. It is already a
pain that the same format rules are going to be specified for every date
that is presented via intake - we need to be able to define rulesets to
apply to fields to get over this.
I posted a link earlier today to a wiki - Quinton put a bunch of intake
wish-list items up there some time ago.
Cheers,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
Re: Intake Patch for 2.3.1 Branch
Posted by Colin Chalmers <Co...@xs4all.nl>.
Hi Scott,
Thx for applying the patch.
I removed the toString in the DateString because I found the code to be
redundant since it was basically performing an action that had already
been done; ie converting the Date Object to a String (stringValue). This
value is also returned using the Field.toString() method. So I found the
overriding method to be duplicate code.
This is also what I meant with trying to simplify the IntakeCode. I feel
there are too many variables with similiar names without a clear
distinction as to what they actually do and a couple of methods which
seem to duplicate code, all by all making the Intake code more
complicated than necessary.
On a side note, the date is presented using the first format in the
available acceptable formats, would it not be better to display using
localized format?
Colin
Scott Eade wrote:
> Colin Chalmers wrote:
>
>> This patch fixes the problem identified by Scott whereby the correct
>> date format was not being shown on screen, instead a toString Dump of
>> the Date Object was being shown. In order to use the patch you should
>> change the reference to the value in Template from
>>
>> $group.foo.Value
>> to
>> $group.foo.StringValue
>>
>> which will then show the correctly formatted date. This can (but
>> doesn't have to) be used for all Values and not just Dates.
>>
>> Can someone check this in? Scott let me know if this solves the problem.
>
>
> While you patch improves the situation in that the format in which the
> data is entered is retained, this is not how I believe DateString is
> supposed to behave. The toString() method you removed from DateString
> attempts to format the date using the first format rule provided for
> the field which is desirable for two reasons:
> 1. It provides the format to use for a date that has been retrieved
> from the database
> 2. It will convert the entered data into the most desirable format for
> the field.
>
> I had a quick play with this and and found that the desired behaviour
> could be achieved by simply retaining the toString() code in
> DateString that is removed by your patch.
>
> As part of the commit I have also changed the behaviour slightly in
> that the DateStringValidator parse() method will attempt to format the
> String as a date using the "formatn" (where "n" = 1,2...) rules before
> trying the "format" rule. This allows me to enter "01/01/03" into a
> field defined as follows and have the year set to 2003 (without this
> change the "format1" rule would never be applied as the "format" rule
> would always process the date as the year 0003):
> <field name="MyDate" key="mdate" type="DateString">
> <rule name="required" value="false">Please enter a value.</rule>
> <rule name="flexible" value="true"/>
> <rule name="format" value="d/MM/yyyy">Please enter a sensible date
> ("dd/mm/yyyy").</rule>
> <rule name="format1" value="d/MM/yy">Please enter a sensible date
> ("dd/mm/yyyy").</rule>
> </field>
>
> Thanks for your patch - it, plus a little additional work appears to
> make DateString usable and will allow me to cull out a bunch of code
> that I have used in the past to validate dates.
>
> I will commit this shortly.
>
> Scott
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Intake Patch for 2.3.1 Branch
Posted by Colin Chalmers <Co...@xs4all.nl>.
Hi Scott,
Thx for applying the patch.
I removed the toString in the DateString because I found the code to be
redundant since it was basically performing an action that had already
been done; ie converting the Date Object to a String (stringValue). This
value is also returned using the Field.toString() method. So I found the
overriding method to be duplicate code.
This is also what I meant with trying to simplify the IntakeCode. I feel
there are too many variables with similiar names without a clear
distinction as to what they actually do and a couple of methods which
seem to duplicate code, all by all making the Intake code more
complicated than necessary.
On a side note, the date is presented using the first format in the
available acceptable formats, would it not be better to display using
localized format?
Colin
Scott Eade wrote:
> Colin Chalmers wrote:
>
>> This patch fixes the problem identified by Scott whereby the correct
>> date format was not being shown on screen, instead a toString Dump of
>> the Date Object was being shown. In order to use the patch you should
>> change the reference to the value in Template from
>>
>> $group.foo.Value
>> to
>> $group.foo.StringValue
>>
>> which will then show the correctly formatted date. This can (but
>> doesn't have to) be used for all Values and not just Dates.
>>
>> Can someone check this in? Scott let me know if this solves the problem.
>
>
> While you patch improves the situation in that the format in which the
> data is entered is retained, this is not how I believe DateString is
> supposed to behave. The toString() method you removed from DateString
> attempts to format the date using the first format rule provided for
> the field which is desirable for two reasons:
> 1. It provides the format to use for a date that has been retrieved
> from the database
> 2. It will convert the entered data into the most desirable format for
> the field.
>
> I had a quick play with this and and found that the desired behaviour
> could be achieved by simply retaining the toString() code in
> DateString that is removed by your patch.
>
> As part of the commit I have also changed the behaviour slightly in
> that the DateStringValidator parse() method will attempt to format the
> String as a date using the "formatn" (where "n" = 1,2...) rules before
> trying the "format" rule. This allows me to enter "01/01/03" into a
> field defined as follows and have the year set to 2003 (without this
> change the "format1" rule would never be applied as the "format" rule
> would always process the date as the year 0003):
> <field name="MyDate" key="mdate" type="DateString">
> <rule name="required" value="false">Please enter a value.</rule>
> <rule name="flexible" value="true"/>
> <rule name="format" value="d/MM/yyyy">Please enter a sensible date
> ("dd/mm/yyyy").</rule>
> <rule name="format1" value="d/MM/yy">Please enter a sensible date
> ("dd/mm/yyyy").</rule>
> </field>
>
> Thanks for your patch - it, plus a little additional work appears to
> make DateString usable and will allow me to cull out a bunch of code
> that I have used in the past to validate dates.
>
> I will commit this shortly.
>
> Scott
>
Re: Intake Patch for 2.3.1 Branch
Posted by Scott Eade <se...@backstagetech.com.au>.
Colin Chalmers wrote:
> This patch fixes the problem identified by Scott whereby the correct
> date format was not being shown on screen, instead a toString Dump of
> the Date Object was being shown. In order to use the patch you should
> change the reference to the value in Template from
>
> $group.foo.Value
> to
> $group.foo.StringValue
>
> which will then show the correctly formatted date. This can (but
> doesn't have to) be used for all Values and not just Dates.
>
> Can someone check this in? Scott let me know if this solves the problem.
While you patch improves the situation in that the format in which the
data is entered is retained, this is not how I believe DateString is
supposed to behave. The toString() method you removed from DateString
attempts to format the date using the first format rule provided for the
field which is desirable for two reasons:
1. It provides the format to use for a date that has been retrieved from
the database
2. It will convert the entered data into the most desirable format for
the field.
I had a quick play with this and and found that the desired behaviour
could be achieved by simply retaining the toString() code in DateString
that is removed by your patch.
As part of the commit I have also changed the behaviour slightly in that
the DateStringValidator parse() method will attempt to format the String
as a date using the "formatn" (where "n" = 1,2...) rules before trying
the "format" rule. This allows me to enter "01/01/03" into a field
defined as follows and have the year set to 2003 (without this change
the "format1" rule would never be applied as the "format" rule would
always process the date as the year 0003):
<field name="MyDate" key="mdate" type="DateString">
<rule name="required" value="false">Please enter a value.</rule>
<rule name="flexible" value="true"/>
<rule name="format" value="d/MM/yyyy">Please enter a sensible date
("dd/mm/yyyy").</rule>
<rule name="format1" value="d/MM/yy">Please enter a sensible date
("dd/mm/yyyy").</rule>
</field>
Thanks for your patch - it, plus a little additional work appears to
make DateString usable and will allow me to cull out a bunch of code
that I have used in the past to validate dates.
I will commit this shortly.
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
Re: Intake Patch for 2.3.1 Branch
Posted by Scott Eade <se...@backstagetech.com.au>.
Colin Chalmers wrote:
> This patch fixes the problem identified by Scott whereby the correct
> date format was not being shown on screen, instead a toString Dump of
> the Date Object was being shown. In order to use the patch you should
> change the reference to the value in Template from
>
> $group.foo.Value
> to
> $group.foo.StringValue
>
> which will then show the correctly formatted date. This can (but
> doesn't have to) be used for all Values and not just Dates.
>
> Can someone check this in? Scott let me know if this solves the problem.
While you patch improves the situation in that the format in which the
data is entered is retained, this is not how I believe DateString is
supposed to behave. The toString() method you removed from DateString
attempts to format the date using the first format rule provided for the
field which is desirable for two reasons:
1. It provides the format to use for a date that has been retrieved from
the database
2. It will convert the entered data into the most desirable format for
the field.
I had a quick play with this and and found that the desired behaviour
could be achieved by simply retaining the toString() code in DateString
that is removed by your patch.
As part of the commit I have also changed the behaviour slightly in that
the DateStringValidator parse() method will attempt to format the String
as a date using the "formatn" (where "n" = 1,2...) rules before trying
the "format" rule. This allows me to enter "01/01/03" into a field
defined as follows and have the year set to 2003 (without this change
the "format1" rule would never be applied as the "format" rule would
always process the date as the year 0003):
<field name="MyDate" key="mdate" type="DateString">
<rule name="required" value="false">Please enter a value.</rule>
<rule name="flexible" value="true"/>
<rule name="format" value="d/MM/yyyy">Please enter a sensible date
("dd/mm/yyyy").</rule>
<rule name="format1" value="d/MM/yy">Please enter a sensible date
("dd/mm/yyyy").</rule>
</field>
Thanks for your patch - it, plus a little additional work appears to
make DateString usable and will allow me to cull out a bunch of code
that I have used in the past to validate dates.
I will commit this shortly.
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org