AW: More control over Cform Date Conversion
Hi Edward
To access the entered value in a CForm I use the following construct based
on a personal server side javascript function.
...
return checkFormInputDate(widget);
function checkFormInputDate (widget, regExpValidation,
regExpValidationError)
{
var enteredValue = new
String(cocoon.request.getParameter(widget.getRequestParameterName()));
...
}
Raffaele
-Ursprüngliche Nachricht-
Von: Edward Elhauge [mailto:e...@uncanny.net]
Gesendet: Mittwoch, 4. Februar 2009 02:05
An: users@cocoon.apache.org
Betreff: [?? Probable Spam] More control over Cform Date Conversion
Hi,
I've run into a problem where my users want more detailed control over
Date field validation. In the version that we're running (2.1.8)
we don't have a "lenient" attribute for base="date" widgets.
So the user can type in "33/60/9z" as a date, which get converted into
"10/30/2011". Not what was expected.
What I'd like would be to a small:
...
section to throw an error in those cases.
Unfortunately this.value inside that javascript callback is already in a
Date format.
My question is:
How do I get access to the users original text input
within the fd:validation section?
If there is no way to get access to the raw text, do I need to write
my own validator to replace "FormattingDateConvertor" ?
--
Edward Elhauge
"The right dose differentiates a poison and a remedy." -- Paracelsus (1493 -
1541)
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Using Dojo color picker with CForms?
using 2.18 Has anyone figured out a way to use the Dojo color picker http://www.roseindia.net/dojo/dojo-color-picker-example.shtml with CForms - this email seems to be related, but does not address the issue directly http://marc.info/?l=xml-cocoon-users&m=122457953028491&w=2 Thanks Derek -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: How to get the session attribute in bean
asif_zzz wrote:
Hi Andre,
I found out how to get the session value in Custom Validator class or
Custom-Dynamic SelectionList class
But still i dont no how get the session value from a java class ,such that
the java class does not have any of its references to form(Cforms).
Sorry, I cannot help you with this particular problem. I am not sure
whether I actually understand your question. The session object would
not have references to forms.
I think it may work for ActionListener class as well.
Its a temporary solution.
test
Sample Code:
---
public class TestSelectionList extends AbstractJavaSelectionList implements
Contextualizable {
..
@Override
protected boolean build() throws Exception {
..
Request request = ContextHelper.getRequest(this.context);
String userId = "";
if(request.getSession().getAttribute("userId") != null) {
userId = request.getSession().getAttribute("userId").toString();
}
}
public void contextualize(Context context) throws ContextException {
this.context = context;
}
}
--
Andre H. Juffer | Phone: +358-8-553 1161
Biocenter Oulu and | Fax: +358-8-553-1141
Department of Biochemistry | Email: andre.juf...@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
StruBioCat | WWW: www.strubiocat.oulu.fi
NordProt | WWW: www.nordprot.org
Triacle Biocomputing | WWW: www.triacle-bc.com
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: AW: More control over Cform Date Conversion
Thanks,
A good trick.
Almost does what I want. Problem below.
Well spoken Merico Raffaele wrote:
>Hi Edward
>
>To access the entered value in a CForm I use the following construct based
>on a personal server side javascript function.
>
>
>
> ...=09
>
>
>
> return checkFormInputDate(widget);
>
>
>
>
>
>function checkFormInputDate (widget, regExpValidation,
>regExpValidationError)
>{
>=09
> var enteredValue =3D new
>String(cocoon.request.getParameter(widget.getRequestParameterName()));
> ...
>}
Let's say you have a date like 0/0/0, you detect its bogousity in your
fd:validation
and display an error message. Meanwhile your date field just became 11/30/0002,
because the conversion went on and reinitializes the field. The user looks
casually
(or is fixing a bunch of other RED EXCLAMATION MARKS above) and resubmits the
form.
Now the date field is validated, but not what the user typed in the first time,
and not what they would have fixed it to.
For this to work I need to keep the control of the field in the user's hands
and not
have the system make a wild guess.
Thanks for the trick though,
Ed Elhauge
>Raffaele
>
>-Urspr=FCngliche Nachricht-
>Von: Edward Elhauge [mailto:e...@uncanny.net]=20
>Gesendet: Mittwoch, 4. Februar 2009 02:05
>An: users@cocoon.apache.org
>Betreff: [?? Probable Spam] More control over Cform Date Conversion
>
>Hi,
>
>I've run into a problem where my users want more detailed control over
>Date field validation. In the version that we're running (2.1.8)
>we don't have a "lenient" attribute for base=3D"date" widgets.
>
>So the user can type in "33/60/9z" as a date, which get converted into
>"10/30/2011". Not what was expected.
>
>What I'd like would be to a small:
>
> ...
>
>section to throw an error in those cases.
>
>Unfortunately this.value inside that javascript callback is already in a
>Date format.
>
>My question is:
> How do I get access to the users original text input
> within the fd:validation section?
>
> If there is no way to get access to the raw text, do I need to write
> my own validator to replace "FormattingDateConvertor" ?
--
Edward Elhauge
"The right dose differentiates a poison and a remedy." -- Paracelsus (1493 -
1541)
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Getting started with C2.2 -- where's the exception information?
Andreas No; I did not say that I thought 2.1 *was* unsupported, just that I hoped it would not be. Believe me, I do really appreciate the generous effort and commitment from the experts that helps out those of who do not "get" all the nuances as quickly. I also did not take any offence - the Cocoon mailing list is actually one of the most amazingly friendly and non-critical lists I know; we all have our little rants from time-to-time, but everyone takes it calmly and no one overreacts. Finally< its good to see that projects are/have been making use of 2.2; that will help shake out the bugs and hopefully build towards some solid docs for it. I am especially looking forward to more of the "migrating from 2.1" stories and documents (which is where I suspect many are or might be going); as well as other entry-level cases round Maven and the like. For me, I am very happy that Cocoon has such a solid development team who have a clear direction for it. Derek >>> On 2009/02/03 at 05:11, in message , Andreas Hartmann wrote: Hi Derek, > I agree from a *marketing* perspective that putting buzzwords > on your site is a way to attract new users - especially those who > might otherwise be going to .NET or Ruby-on-Rails - not that I mean > to imply the developers are doing this for that reason alone. > > However, there is also such a thing as a "legacy" application; > while you (or others) might think that languages such as COBOL, > FORTRAN, Pascal etc are "dead", I can almost guarantee you > there are millions of lines of code in those tools being written > or maintained every year (C# notwithstanding). > > There are many of us who have been using Cocoon for many > years now, and I would really hate to think we'll just be dumped > because some new ideas or support frameworks have emerged. do you have the feeling that the 2.1 branch is not sufficiently supported anymore? If I understand Betrand correctly, it is officially in maintenance mode and it is not planned to cease support. We (the Lenya community) are certainly going to need it for another couple of years, so we'll be bound to maintain it. > Personally, I'd also like to see the documentation develop and > mature a little more - there are certainly *lots* of "getting started" > questions in the ML about 2.2 - and a book or half would also > provide some reassurance that a solid new ship is ready for all > types of sailors. +1 > So yes, I am prepared to learn - no doubt I will have to - but it > does not yet feel the right time for what appears to require a > significant upheaval. Sorry if my mail caused any offence or could be taken personally, that was not my intention. I only wanted to express the viewpoint of another type of Cocoon user * the projects which depend on it. Thanks for your reply! -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01 - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
