Re: Getting started with C2.2 -- where's the exception information?
Klortho schrieb: dhohls wrote: That's a little harsh - although my impression is that C2.2 is perhaps a step sideways in terms of how many things are done... but that's just an impression from reading all the mailing list QA. So far, I have not needed to take the plunge. Yes, you're right ... too harsh. I'm really just a newbie, but speaking as one, I think that 2.1 was a much nicer experience out of the gate, which is pretty damn important for an application to gain wider acceptance. BTW, there's also a different viewpoint: Lenya community hat For us, as a project depending on Cocoon, it is crucial that Cocoon doesn't cling to dead (as in language) concepts and frameworks as XSP and Avalon, however proven and stable they may be. To attract new community members, it's very important to keep looking beyond one's own nose and stay in touch with current trends in the Java world. Putting Based on Maven and Spring on your homepage sounds much better at the moment than Based on Ant and Avalon. And we shouldn't be afraid of learning – familiar concepts often seem to be easier to understand than new ones. /Lenya community hat Just my $0.02. -- 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
Re: Getting started with C2.2 -- where's the exception information?
Andreas Do you want the short reply or the long reply :) Short: There needs to be room in the Cocoon universe for 2.1 users as well as 2.2 users. Long: This is the classic issue isn't it!? Certainly we are beset by the culture of the new at present; where new == better - be it cellphones, politicians, or computer languages. 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. 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. 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. My 2(non-Euro)c Derek On 2009/02/03 at 03:44, in message gm9hos$cn...@ger.gmane.org, Andreas Hartmann andr...@apache.org wrote: Klortho schrieb: dhohls wrote: That's a little harsh - although my impression is that C2.2 is perhaps a step sideways in terms of how many things are done... but that's just an impression from reading all the mailing list QA. So far, I have not needed to take the plunge. Yes, you're right ... too harsh. I'm really just a newbie, but speaking as one, I think that 2.1 was a much nicer experience out of the gate, which is pretty damn important for an application to gain wider acceptance. BTW, there's also a different viewpoint: Lenya community hat For us, as a project depending on Cocoon, it is crucial that Cocoon doesn't cling to dead (as in language) concepts and frameworks as XSP and Avalon, however proven and stable they may be. To attract new community members, it's very important to keep looking beyond one's own nose and stay in touch with current trends in the Java world. Putting Based on Maven and Spring on your homepage sounds much better at the moment than Based on Ant and Avalon. And we shouldn't be afraid of learning * familiar concepts often seem to be easier to understand than new ones. /Lenya community hat Just my $0.02. -- 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
Re: Getting started with C2.2 -- where's the exception information?
Hi Derek, Derek Hohls schrieb: […] 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
Re: Getting started with C2.2 -- where's the exception information?
Hi, For us, as a project depending on Cocoon, it is crucial that Cocoon doesn't cling to dead (as in language) concepts and frameworks as XSP and Avalon, however proven and stable they may be. To attract new community members, it's very important to keep looking beyond one's own nose and stay in touch with current trends in the Java world. Putting Based on Maven and Spring on your homepage sounds much better at the moment than Based on Ant and Avalon. And we shouldn't be afraid of learning – familiar concepts often seem to be easier to understand than new ones. As Derek pointed out, it's not a matter of learning - we all have to, not only about Cocoon, don't we ;-) ? - and for sure Based on Maven and Spring sounds more attractive. But at the moment attractive or sounds better is not my major concern. In the _real_ world, there are lots of 2.1 running apps that must work and keep being supported. And it's a good news that 2.1 is still in maintenance mode as Bertrand recently wrote :-). Cheers, André - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
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: fd:validation fd:javascript ... /fd:javascript /fd:validation 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 e...@uncanny.net 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: More control over Cform Date Conversion
Hi Edward, the problem is in conversion, not in validation. When a form value is filled by the user, it is a plain string. Then it arrives to Cocoon, that parse the string to convert it to the proper type, for example a date. After that conversion has been performed successfully, then validation is performed on the obtained converted value, for example the Date object. So, it is not possible to check the string value from a validator, unless you are trying on a string field :) You should be able to take the java source code of the date converter from a recent 2.1.x version of Cocoon, a version that supports the lenient attribute, and backport it to the 2.1.8 version. Hope this helps, Simone Edward Elhauge wrote: 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: fd:validation fd:javascript ... /fd:javascript /fd:validation 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 ? -- Simone GianniCEO Semeru s.r.l. Apache Committer http://www.simonegianni.it/ - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: More control over Cform Date Conversion
* Simone Gianni simo...@apache.org wrote on [2009-02-03 17:25]: Hi Edward, the problem is in conversion, not in validation. When a form value is filled by the user, it is a plain string. Then it arrives to Cocoon, that parse the string to convert it to the proper type, for example a date. After that conversion has been performed successfully, then validation is performed on the obtained converted value, for example the Date object. So, it is not possible to check the string value from a validator, unless you are trying on a string field :) That's what I figured when I started poking about, but I was hoping that the original user input was tucked away somewhere in the Widget. You should be able to take the java source code of the date converter from a recent 2.1.x version of Cocoon, a version that supports the lenient attribute, and backport it to the 2.1.8 version. So I basically have to roll my own replacement FormattingDateConvertor, which I can crib from a more recent version. Hope this helps, Simone Yes, thank you. Knowing that you can stop looking is a BIG help. Cheers, Ed Elhauge Edward Elhauge wrote: 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: fd:validation fd:javascript ... /fd:javascript /fd:validation 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 ? -- Simone GianniCEO Semeru s.r.l. Apache Committer http://www.simonegianni.it/ - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org ---end quoted text--- -- Edward Elhauge e...@uncanny.net 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: How to get the session attribute in bean
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).
I think it may work for ActionListener class as well.
Its a temporary solution.
fd:field id=test
fd:labeli18n:texttest/i18n:text/fd:label
fd:datatype base=string/
fd:selection-list type=java nullable=false
class=com.sample.TestSelectionList/
/fd:field
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;
}
}
--
View this message in context:
http://www.nabble.com/How-to-get-the-session-attribute-in-bean-tp20089416p21825696.html
Sent from the Cocoon - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
