Re: [RT] How scripting made me hate java

[Niclas Hedhman]

On Sunday 20 February 2005 04:58, Sylvain Wallez wrote:
> > But if I have to discuss each and every feature with 20 people -
> > everyone having it's own ideas - I'm most times blocked: 5 people like
> > the idea, 3 people don't like the idea and so you're doomed.
>
> I strongly disagree with your point of view: it's bad to do things on
> your own and then inform people of what you do when it's finished and
> committed.

End of the day, Carsten does what he likes. It is his choice whether community 
feedback 'a priori' will help (views overlooked, possible unthought of 
incompatibilities, and so on) or hinder (never coming to a timely conclusion) 
his progress.

I'd rather see Carsten being enthusiastically hacking about in the code than 
being sick and tired of debates, with a potential risk of "I give up." (God 
forbid).

Cheers
Niclas

Re: [RT] How scripting made me hate java

[Sylvain Wallez]

Carsten Ziegeler wrote:

So, my opinion is we should just look at what people want to use, what 
*we* thing is the best to have, combine those two and then: just do 
it. The past showed that first discussing things lead to no code while 
first coding somethings and then start a discussion based on the code 
works very well. Even if the code is totally changed or removed, it 
seems to be the better way.

And this is what I'm currently trying to do: I'm doing a lot of 
projects with Cocoon and I'm talking to many users of Cocoon. While 
they use Cocoon in different areas, they all have the same problems 
and even we - working with Cocoon for nearly 5 years now - have 
similar problems. So I'm taking the feedback, add my own thoughts and 
implement ideas to see where this may lead. With the current core we 
have a good base to implement new things. It's our own code and we can 
add new features like AOP or JMX support there without any problems.
But if I have to discuss each and every feature with 20 people - 
everyone having it's own ideas - I'm most times blocked: 5 people like 
the idea, 3 people don't like the idea and so you're doomed.

I strongly disagree with your point of view: it's bad to do things on 
your own and then inform people of what you do when it's finished and 
committed. Sure, you may have no problem with other people deeply 
modifying your code afterwards, but you have to understand that not 
everybody feels the same and that people are respectful of other's work 
because of the time and energy it represents. Especially when that code 
comes from one of the core developers.

Now that doesn't mean everything should be discussed and voted, but that 
you need to inform people of the directions you want to take, the 
prototypes you want to try, etc.

Why so? First of all, we are a community, and not a group of individuals 
each working in their corner of a shared SVN repository. Understanding 
the commits flowing on the mailing list is easier if we know a bit what 
they're about beforehand.

Secondly, other people can bring you other point of views and other ways 
to tackle a problem and our collective brain is far more powerful than 
the sum of our invidual brains. Otherwise, why would we be involved in 
OSS projects?

And finally, even if you accept that your code is deeply refactored, 
this represents a lot of wasted energy for you and for others to 
understand and refactor afterwards rather than giving their inputs 
earlier. By knowing earlier, at least people will have the occasion to 
think about the problem and maybe understand what you do and why you do it.

And all this doesn't prevent "just do it": tell people that you *will* 
just do it rather than saying that you just *did* it. Community-wise, 
because that's where we have a problem also, this makes a big difference.

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Enctype + CachingURI Coplet

[Philippe Guillard]

Hi,
I know that portal-html-eventlink doesn't delete enctype attribute 
anymore (http://issues.apache.org/bugzilla/show_bug.cgi?id=28095)
Anyway i can't make my upload form work anymore in a cachingURI coplet, 
cocoon2.1.6, (I updated HTMLEventLinkTransformer.java to last revision 
122957 that i found.)

I get "visually" no continuation and the form is submitted again, 
loosing my input.
The point is, when i suppress the part 'enctype="multipart/form-data" ', 
i have continuation ok!!

My Template



(tried also   with stemap equivalent)


Rendered html, that seems ok to me

http://apache.org/cocoon/portal/coplet/1.0"; 
method="POST" onsubmit="forms_onsubmit(); " action="portal">




Anybody any idea ??
Regards,
Phil

DO NOT REPLY [Bug 27604] - Cocoon Forms stylesheet reports error if xsltc used

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=27604





--- Additional Comments From [EMAIL PROTECTED]  2005-02-19 16:49 ---
Just had a look at the bug over there in the Xalan repository. If I get it right
they say that XLTC is right in complaining about the stylesheets and they are
more likely to fix xalan in order to report the error. So maybe we should
double-check the stylesheets agains the spec to avoid the advanced-field-styling
to be completely broken with the next parser updates.

BTW: I found that if you switch from forms-advanced-field-styling.xsl to
forms-field-styling.xsl you don't only loose the fancy calendar input but
 elements will also be ignored. That renders it unusable.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Fixing i18n required messages

[Mark Lowe]

Looks like this is fixed in the head version out of svn. I find myself
impressed with the responsible choice of technologies for this project
I've walked into. As if cforms wasn't bleeding edge enough, now forced
to use the head version of a block in the trunk.

Anyway, the sample app works (localised messages) in the svn trunk. 

Mark

On Fri, 18 Feb 2005 13:00:14 +0100, Mark Lowe <[EMAIL PROTECTED]> wrote:
> Just to confirm the sample apps have the same bug.. I guess that got
> missed while everyone was rapid application developing at such a fast
> pace..
> 
> Interestingly there's no static variable I18N_CATALOGUE in Contants,
> unless its secretly added during some tourtured build process.. Also
> interesting there's no obvious error when this fails, this could
> perhaps be something to do with a finally block that claims the field
> is validated even in the event of an error here's the comment:
> 
> // Consider validation finished even in case of exception
> this.valueState = VALUE_VALIDATED;
> 
> I cant express how impressed I am.
> 
> Mark
> 
> On Thu, 17 Feb 2005 16:17:54 +0100, Mark Lowe <[EMAIL PROTECTED]> wrote:
> > I've got all that working (localized error messages) and such like,
> > thats all find and dandy. Its just the required field.. The situation
> > has been complicated where I'm walking into a project thats already in
> > progress and, So this could be down to the xslt for form rendering.
> >
> > However I was reading that the required attribute and rendering a
> > localised message wasn't working in the sample either. So I thought
> > I'd take a look into it, rather than whining about it. Guess ist time
> > to run the examples again to see if they do what they say on the box.
> >
> > Mark
> >
> > On Thu, 17 Feb 2005 15:49:06 +0100 (CET), Daniele Madama
> > <[EMAIL PROTECTED]> wrote:
> > >
> > > > I found that, and yes of course I have the message keys added.. You
> > > > should try it, practice is usually better than theory. I've seen this
> > > > mentioned elsewhere, if its a bug I'd prefer to submit a patch when i
> > > > enter it rather than just joining a que.
> > >
> > > If you see the form-instance you can found the declaration of
> > > validation-message
> > >
> > > general.field-required
> > >
> > > so this message must be in the 'forms' catalogue, if you want to have the
> > > message in the same file of other message you can simply add another
> > > catalogue on the declaration of I18nTransformer that point on the same
> > > file
> > >
> > >   > >name="i18n"
> > >label="i18n"
> > >logger="sitemap.transformer.i18n"
> > >src="org.apache.cocoon.transformation.I18nTransformer">
> > >  
> > > > > location="resources/translations"/>
> > > > > location="resources/translations"/>
> > >  
> > >  false
> > >  
> > >
> > > in this code both catalogue point to the same file.
> > >
> > > Is this all or your sitatuion is different?
> > >
> > > TIA,
> > > Best regards
> > >
> > > >
> > > > On Thu, 17 Feb 2005 11:40:37 +0100 (CET), Daniele Madama
> > > > <[EMAIL PROTECTED]> wrote:
> > > >>
> > > >> > Hello
> > > >> >
> > > >> > Could someone nudge me in the right direction (i.e. where to start
> > > >> > looking) if i wanted to get a patch in to fix this annoying i18n
> > > >> > required messages problem.
> > > >> >
> > > >> > Thanks
> > > >> >
> > > >> > Mark
> > > >> >
> > > >>
> > > >> If you are looking for the i18n of the cforms required message, is
> > > >> already
> > > >> done in the o.a.c.forms.formmodel.Field class
> > > >>
> > > >> 
> > > >>if (this.value == null && getFieldDefinition().isRequired())
> > > >> {
> > > >>// Field is required
> > > >>this.validationError = new ValidationError(new
> > > >> I18nMessage("general.field-required",
> > > >> Constants.I18N_CATALOGUE));
> > > >>} else {
> > > >> 
> > > >>
> > > >> So the only things is to add the correct message entry in the i18n
> > > >> catalog.
> > > >>
> > > >> I hope this is what you need.
> > > >>
> > > >> Best regards
> > > >>
> > > >> --
> > > >> Daniele Madama
> > > >>
> > > >> Pro-netics s.r.l.
> > > >> Via Elio Lampridio Cerva 127/c
> > > >> Roma
> > > >> Tel. 0651530849
> > > >> http://www.pro-netics.com
> > > >>
> > > >
> > >
> > > --
> > > Daniele Madama
> > >
> > > Pro-netics s.r.l.
> > > Via Elio Lampridio Cerva 127/c
> > > Roma
> > > Tel. 0651530849
> > > http://www.pro-netics.com
> > >
> >
>