RE: Documentation TOC started

[H . vanderLinden]

Hi David,

> Good idea and i admire your enthusiasm. 

Thanks.

> You will see my additions to that page were i tried to ensure

Yes I noticed.

> that it only links to local Cocoon documentation. Already i see
> that people are not heeding that, and linking off to all sorts of
> remote stuff. It may end up just being a jump page to everything.

Well, at first I like this page to be a kind of inventory to available and
missing documentation. After that I think it needs to be structured, with
some pages possibly rewritten and end up in the xdoc section. My ultimate
goal is an ebook kind of documentation.
Part of the documentation in my view is also a section on "Cocoon info in
the rest of the world", although this might very well be a wiki page.

> Please also scan the dev@ and the old docs@ archives.
> This TOC topic has been discussed and commenced many times.

:-) I'm sure it has, I'll have a look.

> I think that such pages will need very clear intentions and
> monitoring to keep on track.

Is the above clear enough?

Bye, Helma

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

[Reinhard Pötz]

Nicola Ken Barozzi wrote:

Ugo Cei wrote:

I think everyone interested has had the option of venting his opinion 
on the subject of checked vs. unchecked exceptions. For the record, 
here [1] is the relevant thread.

In order to move forward, I propose to reparent the 
org.apache.cocoon.ProcessingException to extend 
org.apache.avalon.framework.CascadingRuntimeException instead of 
CascadingException.

The change is backward-compatible and is a one-line change that can 
be reverted easily, but might have implications on the way we manage 
exceptions in the future.

I've already performed the change locally and everything compiles. 
Tests fail, but they failed also before the change :-(.

So, please cast your votes.


-1

Nicola, could you summarize the reasons for your -1?
(... I haven't followed the previous discussion on exceptions very 
closely, so pls forgive if you already pointed out your concerns)

--
Reinhard

Re: forms block does not build

[Marc Portier]

Jonas Ekstedt wrote:

Hello

I get following errors when I build cocoon:

Compiling 18 source files to
/opt/dev/cocoon-2.1/build/cocoon-2.1.5-dev/blocks/forms/dest
/opt/dev/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/transformation/EffectWidgetReplacingPipe.java:288:
 cannot assign a value to final variable attrs
input.attrs = attrsCopy;
 ^
/opt/dev/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/transformation/EffectWidgetReplacingPipe.java:289:
 cannot resolve symbol
symbol  : variable mine
location: class
org.apache.cocoon.forms.transformation.EffectPipe.Element
input.mine = true;
 ^
2 errors
Cheers
// Jonas
 
Jonas,

be sure to have a recent and clean cvs checkout or either an official 
source-release of cocoon

it looks like your version of the EffectWidgetReplacingPipe.java is not 
in sync with the EffectPipe.java (there have been some recent additions 
to both)

regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

[Nicola Ken Barozzi]

Ugo Cei wrote:
I think everyone interested has had the option of venting his opinion on 
the subject of checked vs. unchecked exceptions. For the record, here 
[1] is the relevant thread.

In order to move forward, I propose to reparent the 
org.apache.cocoon.ProcessingException to extend 
org.apache.avalon.framework.CascadingRuntimeException instead of 
CascadingException.

The change is backward-compatible and is a one-line change that can be 
reverted easily, but might have implications on the way we manage 
exceptions in the future.

I've already performed the change locally and everything compiles. Tests 
fail, but they failed also before the change :-(.

So, please cast your votes.
-1

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: Help with binding - CFORMS

[Marc Portier]

Daniel Fagerstrom wrote:

Marc Portier wrote:

For the interested reader, some more info:
[1 - on the reported error]
The error 'factory is not set' from jxpath indicates that no 
node-factory (jxpath terminology) is available (to the jxpath context) 
to create new 'nodes' in the backend (i.e. a bigger array in the bean, 
or additional objects to add to the list).

I assume the multi-value binding was only tested versus XML backends 
since those have by default a node-generation factory installed (and 
thus the problem never occurs)


Yes, I only tested the XML binding part. I wrote a note about that in 
ths CVS-log, a note in the javadoc or the wiki-doc that I newer wrote 
had been easier to find I guess ;)

well, objectively they're equally easy to find of course, it really is a 
matter of what comes first to mind (yes, often the wiki :-))

Towards javaBean backends this reveals that the the multi-value lacks 
the feature of declaring such a factory (to compare: this is what the 
 inside the repeater binding is for)

IMHO multi-value binding code looks like an early clone of the 
simple-repeater binding.  This issue kinda re-affirms my feeling that 
there is no reason to maintain this multi-value-binding in the future.


Yes, it is based on the simple-repeater binding code. First I tried to 
reuse the simple-repeater binding whithout doing copy and modify, but 
the data model for the multi-value widget and the repeater widget are 
quite different so it would have required a refactoring of both widgets, 
yep, I realize that, the other approach is to solve everything in some 
wrapper on the side of the binding, but it seems a tad more logical to 
have some RepeatableWidget or IteratableWidget interface that could be 
implemented by both.  That would make it easier for some common binding 
to attach to both.

The feeling I still have is that these repeatable widget-values (i.e. 
the rows to the repeater-widget) would need some notion of their 
'identity' which for a multivalue-field seems to be not-existent (it 
behaves like a bag, not a list), and in other use cases would boil down 
to their 'index' (meaning the identity is their position in the 
surrounding RepeatableWidget)

 and that propagates to a lot of other code in the form framework, 
something that I didn't have time to do when I wrote the binding code :/ 
I agree completely with another of your posts that we have to refactor 
the form code so that it becomes comprehensible and that now is the time 
to do it.

IMO we need better interfaces for the widgets than the current ones: 
Widget and ContainerWidget. If we take a look at the repeater widget it 
 implements ContainerWidget but it does not contain real implementations 
of the (to few) methods of ContainerWidget, instead it uses a number of 
I started a page on the wiki [WoodyRefactoring] to capture the floating 
impl-ideas-on-this-refactoring, feel free to jot down your hints when 
you come down to it...

own methods for accessing its contents. The multi-value field does not 
implement container, but instead uses an Object[] as input and output. 
What we need are interfaces for container widgets that contains enough 
methods so that the "repeater" binding can be written in terms of the 
interface instead of in terms of the repeater class. Then the 
yep I agree, but I think it is another aspect then the Container thing
container == have child-widgets
iteratable == have mutliple values
(I think I now finally parse Peter's hint some weeks ago saying that 
being multi-valueable is just an aspect that could be attached to 
different widgets)

multi-value widget should implement this interface and we could through 
away the mult-value bindning.

good idea.


[2 - on the confusing naming of the bindings]
Of course this leads me to some other observation: the names of the 
bindings are way too look-alike to the names of the widgets!

Because of this the misconception has grown that the binding file is a 
duplicate of your definition file that needs to allocate the matching 
binding-component to the matching widget. THIS IS NOT THE CASE. (see 
e.g. the last binding-sample '03aggregate': there an aggregate widget 
gets bind using both the aggregate-binding and the value-binding: that 
just works, and it's not a hack, nor an after-thought.)


I believe that the "misconception" depends on the weak interfaces for 
the widgets that in turn makes the binding classes more widget specific 
than they ideally should be.

more +1

Need to review the widget and binding classes in more detail to give any 
 more detailed suggestion on what the stricter interfaces should look 
like, though.

WDYT?

good ideas, they surely help clearing out

-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

[Ugo Cei]

Il giorno 16/apr/04, alle 00:02, Ugo Cei ha scritto:

The change is backward-compatible and is a one-line change that can be 
reverted easily, but might have implications on the way we manage 
exceptions in the future.
Actually, we have a few cases of "catch(CascadingException)" here and 
there, that should be examined and maybe fixed too.

	Ugo

forms block does not build

[Jonas Ekstedt]

Hello

I get following errors when I build cocoon:

Compiling 18 source files to
/opt/dev/cocoon-2.1/build/cocoon-2.1.5-dev/blocks/forms/dest
/opt/dev/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/transformation/EffectWidgetReplacingPipe.java:288:
 cannot assign a value to final variable attrs
input.attrs = attrsCopy;
 ^
/opt/dev/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/transformation/EffectWidgetReplacingPipe.java:289:
 cannot resolve symbol
symbol  : variable mine
location: class
org.apache.cocoon.forms.transformation.EffectPipe.Element
input.mine = true;
 ^
2 errors

Cheers
// Jonas
 

Re: [VOTE] Make ProcessingException extend CascadingRuntimeException

[Bertrand Delacretaz]

Le 16 avr. 04, à 00:02, Ugo Cei a écrit :

...In order to move forward, I propose to reparent the 
org.apache.cocoon.ProcessingException to extend 
org.apache.avalon.framework.CascadingRuntimeException instead of 
CascadingException
+1

-Bertrand

DO NOT REPLY [Bug 28424] - [PATCH] Allow applications access to the start and end of a request

[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=28424

[PATCH] Allow applications access to the start and end of a request





--- Additional Comments From [EMAIL PROTECTED]  2004-04-16 03:03 ---
Created an attachment (id=11254)
Patch to call a RequestListener before and after a request

DO NOT REPLY [Bug 28424] New: - [PATCH] Allow applications access to the start and end of a request

[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=28424

[PATCH] Allow applications access to the start and end of a request

   Summary: [PATCH] Allow applications access to the start and end
of a request
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This patch modifies Cocoon.java to have it call a RequestListener before and
after a request if one is defined in Cocoon.xconf.  A sample RequestListener is
provided . The patch to Cocoon.java isn't the prettiest as I didn't want to put
something in the finally block that might cause an exception to get lost.

Re: GroovyMarkup syntax works!

[Antonio Gallardo]

Sylvain Wallez dijo:
> Bertrand Delacretaz wrote:
>
>> Le 15 avr. 04, à 21:40, Antonio Gallardo a écrit :
>>
>>> ...Aparently no O/R mapping suppport.
>>> ==
>>> No researched enough Groovy to said that, but I will not go back to
>>> plain
>>> JDBC and SQL
>>
>>
>> I'm not seeing Groovy SQL support as a replacement for O/R mapping or
>> java-based business logic, but just as a small and simple thing for
>> when you want to go directly to a database.
>>
>> IMO there are many "read-only" publishing applications where direct
>> SQL queries, combined with a powerful script language, are very
>> useful. In this sense, Groovy SQL stuff could be nothing more than an
>> alternative to ESQL or the SQLTransformer
>
>
> +1, although it feels a bit strange to generate XML without pointy
> brackets...
>
> Groovy, baby!!
> (see http://www.oneposter.com/Product-recordCount-1-stockid-5070.html)

Yes. I agreed, but there are still some issues to solve first in this
parentesis oriented grammar. For example, try to write something like:

Hello, bold text 

and you will see the true.

Of course I hope it will fixed soon. ;-)

Best Regards,

Antonio Gallardo

[VOTE] Make ProcessingException extend CascadingRuntimeException

[Ugo Cei]

I think everyone interested has had the option of venting his opinion 
on the subject of checked vs. unchecked exceptions. For the record, 
here [1] is the relevant thread.

In order to move forward, I propose to reparent the 
org.apache.cocoon.ProcessingException to extend 
org.apache.avalon.framework.CascadingRuntimeException instead of 
CascadingException.

The change is backward-compatible and is a one-line change that can be 
reverted easily, but might have implications on the way we manage 
exceptions in the future.

I've already performed the change locally and everything compiles. 
Tests fail, but they failed also before the change :-(.

So, please cast your votes.

	Ugo

[1] http://marc.theaimsgroup.com/?t=10818860842&r=1&w=2

Re: GroovyMarkup syntax works!

[Sylvain Wallez]

Bertrand Delacretaz wrote:

Le 15 avr. 04, à 21:40, Antonio Gallardo a écrit :

...Aparently no O/R mapping suppport.
==
No researched enough Groovy to said that, but I will not go back to 
plain
JDBC and SQL


I'm not seeing Groovy SQL support as a replacement for O/R mapping or 
java-based business logic, but just as a small and simple thing for 
when you want to go directly to a database.

IMO there are many "read-only" publishing applications where direct 
SQL queries, combined with a powerful script language, are very 
useful. In this sense, Groovy SQL stuff could be nothing more than an 
alternative to ESQL or the SQLTransformer


+1, although it feels a bit strange to generate XML without pointy 
brackets...

Groovy, baby!!
(see http://www.oneposter.com/Product-recordCount-1-stockid-5070.html)
Sylvain

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

Jexl and JXPath give different results!

[H . vanderLinden]

Hi,

I've been fiddling around with retrieving info from a custom built object.
For clarity I'll explain the object here:

Class Person {
  private Hashtable cocoonTraits;
  private String ID;
  
  public String getID() { return ID; }
  public Map getTraits() { return cocoonTraits;  }
}

Class CocoonTrait {
  private Hashtable cocoonTraits;
  private Hashtable cocoonValues;
  private String name;
  
  public String getName() { return name; }
  public Map getTraits() { return cocoonTraits;  }
  public Map getValues() { return cocoonValues;  }
}

Class CocoonValue {
  private String name;
  private Object value;
  
  public String getName() { return name; }
  public Object getValue() { return value; }
}

I've instantiated the above and added some values to the CocoonValue
objects. Then I want to display them:

http://apache.org/cocoon/templates/jx/1.0";>

A person

A person = ${person.ID} 


Trait = ${trait.name}


${value.name}${value.value}








#{./name}



#{./name}#{./value}








The first table correctly shows all Trait names and all Value names and the
values of those that are filled in.
The second table only shows:



[EMAIL PROTECTED]



So either I've done something wrong in the syntax (which I cannot conclude
from the docs}, or there is something really wrong.

Bye, Helma

Re: GroovyMarkup syntax works!

[Bertrand Delacretaz]

Le 15 avr. 04, à 21:40, Antonio Gallardo a écrit :
...Aparently no O/R mapping suppport.
==
No researched enough Groovy to said that, but I will not go back to 
plain
JDBC and SQL
I'm not seeing Groovy SQL support as a replacement for O/R mapping or 
java-based business logic, but just as a small and simple thing for 
when you want to go directly to a database.

IMO there are many "read-only" publishing applications where direct SQL 
queries, combined with a powerful script language, are very useful. In 
this sense, Groovy SQL stuff could be nothing more than an alternative 
to ESQL or the SQLTransformer

-Bertrand

Re: GroovyMarkup syntax works!

[Antonio Gallardo]

Bertrand Delacretaz dijo:
> I've just commited a GroovyMarkup [1] generator sample in the BSF
> block, allowing the ScriptGenerator to use syntax like this:
>
> xml.page() {
>  content() {
>  section() {
>  title("GroovyMarkup test")
>
>  p("Look ma, no angle brackets!")
>
>   ul() {
>  for(i in 1..5) {
>  li("This is item " + i)
>  }
>  }
> }
>  }
> }

Great, job!
I expended the most of the time trying to make it work, but without the
fix it was impossible. :-(

> Thanks to James Strachan who very quickly fixed a problem in Groovy's
> SAXBuilder. I've committed a snapshot of the Groovy jar with the fix,
> this will have to be replaced with the next release when it's
> available.

James is really a nice guy, I chatted with him on groovy channel last time
(thanks to Brian). James showed interest in see working Groovy on Cocoon
and of course as a Flow Engine language with continuation support. I will
work again on that this weekend. Hope this time I will success.

> Next step would be to allow the (way cool) Groovy Sql syntax [2] to be
> used for database queries. It should be easy to implement, by making a
> ConnectionProvider available to the scripts so that a groovy.sql.Sql
> object can be created to use Connections from the Cocoon pool (I'm
> thinking of having the ScriptGenerator release them to keep scripts
> simple).

:-D
This is something that was on my head for a while and not sure if this is
good or not. I am still thinking about that. The plus are not needed to
said, my reluntace is, because:

Aparently no O/R mapping suppport.
==
No researched enough Groovy to said that, but I will not go back to plain
JDBC and SQL. I think is not a plus to start designing in this way. But
people can welcome this approach if they use too few tables. This is
diferent and maybe for total no DB-oriented cases this is a great plus.

What I try to said is: SQL support in Groovy is welcomed and it is OK, but
I will not try to encourage people about his usage for DB oriented webapp
in Cocoon. I think we can see a better way in O/R mapping tools.

But maybe there is a way using O/R mapping in Groovy. And this will be great!


Best Regards,

Antonio Gallardo

DO NOT REPLY [Bug 28383] - [cron] OutOfMemoryError

[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=28383

[cron] OutOfMemoryError





--- Additional Comments From [EMAIL PROTECTED]  2004-04-15 18:58 ---
To get it to fail quicker, run it every 3 seconds.  Also, I forgot to mention
that I changed TestCronJob configuration to:
  0.

Re: GroovyMarkup syntax works!

[Leon Widdershoven]

of course, I'm working on a static factory class for myself which does 
only that:)

Bertrand Delacretaz wrote:

Le 15 avr. 04, à 19:37, Leon Widdershoven a écrit :

You don't have access to a ServiceManager or ComponentManager 
(provided by cocoon and holding the
configured pools)?


Sure - it just needs a little bridge to make the pools or Connections 
available to the scripts.

-Bertrand

Re: GroovyMarkup syntax works!

[Bertrand Delacretaz]

Le 15 avr. 04, à 19:37, Leon Widdershoven a écrit :

You don't have access to a ServiceManager or ComponentManager 
(provided by cocoon and holding the
configured pools)?
Sure - it just needs a little bridge to make the pools or Connections 
available to the scripts.

-Bertrand

Re: GroovyMarkup syntax works!

[Leon Widdershoven]

You don't have access to a ServiceManager or ComponentManager (provided 
by cocoon and holding the
configured pools)?

Bertrand Delacretaz wrote:

Le 15 avr. 04, à 18:20, [EMAIL PROTECTED] a écrit :

...You might as well just use DataSource then as this is pretty close 
to all DataSource is. (Or at the least get ConnectionProvider to 
implement DataSource)

There's an implementation in Jakarta Commons dbcp and various JDBC 
drivers come with an implementation of DataSource for you already 
(e.g. Oracle & Axion).

If nothing else just provide a DataSource facade to whatever 
connection pool you use and the groovy.sql.Sql will work fine with 
your pool.


Sounds good, I'll try it!
-Bertrand

Moving ModuleSource out of scratchpad

[Bruno Dumon]

Unless someone complains, I'll move ModuleSource out of the scratchpad
one of the next days.

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: Documentation TOC started

[David Crossley]

Helma.vanderLinden wrote:
> Guys (and girls),
> 
> I want to structure all the documentation about Cocoon in the Wiki and the
> xdocs. I've started small by setting up a Wiki page
> http://wiki.cocoondev.org/Wiki.jsp?page=Cocoon215TOC which should become a
> Table of Contents into documentation geared to Cocoon 2.1.5 and future
> versions.

Good idea and i admire your enthusiasm. 

You will see my additions to that page were i tried to ensure
that it only links to local Cocoon documentation. Already i see
that people are not heeding that, and linking off to all sorts of
remote stuff. It may end up just being a jump page to everything.

> At first I want to fill this page with links to existing Wiki and xdoc
> pages, after that missing pages should be added and outdated pages updated
> or rewritten.
> 
> The first draft of this TOC is far from complete, so I'd like you all to
> take a quick look at the wiki page and add missing items and sections.

Please also scan the dev@ and the old docs@ archives.
This TOC topic has been discussed and commenced many times.

I think that such pages will need very clear intentions and
monitoring to keep on track.

--David

Re: Help with binding - CFORMS

[Daniel Fagerstrom]

Marc Portier wrote:

For the interested reader, some more info:
[1 - on the reported error]
The error 'factory is not set' from jxpath indicates that no 
node-factory (jxpath terminology) is available (to the jxpath context) 
to create new 'nodes' in the backend (i.e. a bigger array in the bean, 
or additional objects to add to the list).

I assume the multi-value binding was only tested versus XML backends 
since those have by default a node-generation factory installed (and 
thus the problem never occurs)
Yes, I only tested the XML binding part. I wrote a note about that in 
ths CVS-log, a note in the javadoc or the wiki-doc that I newer wrote 
had been easier to find I guess ;)

Towards javaBean backends this reveals that the the multi-value lacks 
the feature of declaring such a factory (to compare: this is what the 
 inside the repeater binding is for)

IMHO multi-value binding code looks like an early clone of the 
simple-repeater binding.  This issue kinda re-affirms my feeling that 
there is no reason to maintain this multi-value-binding in the future.
Yes, it is based on the simple-repeater binding code. First I tried to 
reuse the simple-repeater binding whithout doing copy and modify, but 
the data model for the multi-value widget and the repeater widget are 
quite different so it would have required a refactoring of both widgets, 
 and that propagates to a lot of other code in the form framework, 
something that I didn't have time to do when I wrote the binding code :/ 
I agree completely with another of your posts that we have to refactor 
the form code so that it becomes comprehensible and that now is the time 
to do it.

IMO we need better interfaces for the widgets than the current ones: 
Widget and ContainerWidget. If we take a look at the repeater widget it 
 implements ContainerWidget but it does not contain real 
implementations of the (to few) methods of ContainerWidget, instead it 
uses a number of own methods for accessing its contents. The multi-value 
field does not implement container, but instead uses an Object[] as 
input and output. What we need are interfaces for container widgets that 
contains enough methods so that the "repeater" binding can be written in 
terms of the interface instead of in terms of the repeater class. Then 
the multi-value widget should implement this interface and we could 
through away the mult-value bindning.


[2 - on the confusing naming of the bindings]
Of course this leads me to some other observation: the names of the 
bindings are way too look-alike to the names of the widgets!

Because of this the misconception has grown that the binding file is a 
duplicate of your definition file that needs to allocate the matching 
binding-component to the matching widget. THIS IS NOT THE CASE. (see 
e.g. the last binding-sample '03aggregate': there an aggregate widget 
gets bind using both the aggregate-binding and the value-binding: that 
just works, and it's not a hack, nor an after-thought.)
I believe that the "misconception" depends on the weak interfaces for 
the widgets that in turn makes the binding classes more widget specific 
than they ideally should be.

Need to review the widget and binding classes in more detail to give any 
 more detailed suggestion on what the stricter interfaces should look 
like, though.

WDYT?

/Daniel

Re: GroovyMarkup syntax works!

[Bertrand Delacretaz]

Le 15 avr. 04, à 18:20, [EMAIL PROTECTED] a écrit :
...You might as well just use DataSource then as this is pretty close 
to all DataSource is. (Or at the least get ConnectionProvider to 
implement DataSource)

There's an implementation in Jakarta Commons dbcp and various JDBC 
drivers come with an implementation of DataSource for you already 
(e.g. Oracle & Axion).

If nothing else just provide a DataSource facade to whatever 
connection pool you use and the groovy.sql.Sql will work fine with 
your pool.
Sounds good, I'll try it!
-Bertrand

Re: GroovyMarkup syntax works!

[jastrachan]

On 15 Apr 2004, at 17:16, Bertrand Delacretaz wrote:
Le 15 avr. 04, à 18:01, [EMAIL PROTECTED] a écrit :

...BTW you could just create the Sql object with a DataSource which 
is-a JDBC connection pool, then the Sql object takes care of all the 
pooling for you. Is there support for DataSource in Cocoon or some 
kinda adapter between DataSource and ConnectionProvider?...
Dunno about javax.sql.DataSource support, I'll have to check.

ConnectionProvider does not exist yet, I just made it up with the 
following idea:
Ah OK :)

public class ConnectionProvider {
  // Groovy scripts which need a Connection will use this to get
  // it from the Cocoon pool
  public Connection getConnection(String connectionName);
  // then, once the Groovy script has been executed, ScriptGenerator
  // calls this to return all connections provided by getConnection to 
the pool
  public void releaseConnections()
}

In this way, the Groovy script can access any Connections that are 
configured, and does not have to care about releasing them. It's easy 
to implement in case we don't have DataSource support.
You might as well just use DataSource then as this is pretty close to 
all DataSource is. (Or at the least get ConnectionProvider to implement 
DataSource)

There's an implementation in Jakarta Commons dbcp and various JDBC 
drivers come with an implementation of DataSource for you already (e.g. 
Oracle & Axion).

If nothing else just provide a DataSource facade to whatever connection 
pool you use and the groovy.sql.Sql will work fine with your pool.

James
---
http://radio.weblogs.com/0112098/

Re: GroovyMarkup syntax works!

[Bertrand Delacretaz]

Le 15 avr. 04, à 18:01, [EMAIL PROTECTED] a écrit :

...BTW you could just create the Sql object with a DataSource which 
is-a JDBC connection pool, then the Sql object takes care of all the 
pooling for you. Is there support for DataSource in Cocoon or some 
kinda adapter between DataSource and ConnectionProvider?...
Dunno about javax.sql.DataSource support, I'll have to check.

ConnectionProvider does not exist yet, I just made it up with the 
following idea:

public class ConnectionProvider {
  // Groovy scripts which need a Connection will use this to get
  // it from the Cocoon pool
  public Connection getConnection(String connectionName);
  // then, once the Groovy script has been executed, ScriptGenerator
  // calls this to return all connections provided by getConnection to 
the pool
  public void releaseConnections()
}

In this way, the Groovy script can access any Connections that are 
configured, and does not have to care about releasing them. It's easy 
to implement in case we don't have DataSource support.

-Bertrand

Re: GroovyMarkup syntax works!

[jastrachan]

Apologies Bertrand, this mail will bounce off the cocoon list I suspect 
as I'm not a subscriber...

On 15 Apr 2004, at 16:52, Bertrand Delacretaz wrote:
I've just commited a GroovyMarkup [1] generator sample in the BSF 
block, allowing the ScriptGenerator to use syntax like this:

xml.page() {
content() {
section() {
title("GroovyMarkup test")
p("Look ma, no angle brackets!")

ul() {
for(i in 1..5) {
li("This is item " + i)
}
}
   }
}
}
Thanks to James Strachan who very quickly fixed a problem in Groovy's 
SAXBuilder. I've committed a snapshot of the Groovy jar with the fix, 
this will have to be replaced with the next release when it's 
available.

Next step would be to allow the (way cool) Groovy Sql syntax [2] to be 
used for database queries. It should be easy to implement, by making a 
ConnectionProvider available to the scripts so that a groovy.sql.Sql 
object can be created to use Connections from the Cocoon pool (I'm 
thinking of having the ScriptGenerator release them to keep scripts 
simple).
BTW you could just create the Sql object with a DataSource which is-a 
JDBC connection pool, then the Sql object takes care of all the pooling 
for you. Is there support for DataSource in Cocoon or some kinda 
adapter between DataSource and ConnectionProvider?

An alternative is to create a new Sql object per request with a 
specific Connection, then return the connection back to the pool after 
the request has finished. Though the DataSource approach is cleaner I 
think.

James
---
http://radio.weblogs.com/0112098/

RE: Help with binding - CFORMS

[Uchenna Igwebuike]

Hello Mark,

I tried out your suggestions and it works for binding the selected
values from the form to the bean but when I call form.load(bean) ie
binding from bean to form, it doesn't seem to work, the selected values
do not show up on the form. Any thoughts on this?. Thanks in advance. 

NB. I am modeling the field as a long data type.

Uchenna


-Original Message-
From: Marc Portier [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 14, 2004 6:06 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Help with  binding - CFORMS

copying dev since there is some food for design-thought...

Joerg Heinicke wrote:

> On 12.04.2004 16:14, Uchenna Igwebuike wrote:
> 
>> When I bind a form without selecting any data to the bean, I don't
get
>> any errors, but when it contains some selections I get the following
>> error
>>
>> uncaught JavaScript exception: at material
>>
(file:/C:/projects/zes/construction/jboss-3.2.3/server/default/tmp/deplo
>>
y/tmp16629ZESApplication-0.1.ear-contents/Mercury.war/inventory/flow/inv
>> entory.js, Line 64) at
>> (resource://org/apache/cocoon/forms/flow/javascript/Form.js, Line
164):
>> org.apache.commons.jxpath.JXPathException: Exception trying to create
>> xpath measureCollection; Factory is not set on the JXPathContext -
>> cannot create path: /facility[1]
> 
> 
> I guess the problem is only the predicate [1]. JXPath can not create a

> node for an XPath with a predicate. Can you try for testing some thing

> like facility1, facility2 and so on? Of course this looks like a hack,


hm, this will not work IMHO

> but I don't know how you can fix it in a good way. Someone more 
> experienced with JXPath might help here. Marc or Bruno?
> 

Hm, I suppose the predicate is not in the Uchenna's binding file, but 
rather introduced by the execution of the multi-value binding: it wants 
to create a space to store each value from the multi-value array...

Suggestion:
I assume your backend now has some method: Object[] getFacility() that 
produces an array (more likely a List I'm afraid) in which the various 
facilities to be bound are present?
IIf it is acceptable that
1/ the type of this facility would become Object[] (in stead of List)
2/ and you can provide a setFacility(Object[]) accessor as well

then you could find a work-around in using the classic value-binding
(this is because the widget-value is also of type Object[]

Pls let us know if this works for you.


For the interested reader, some more info:
[1 - on the reported error]
The error 'factory is not set' from jxpath indicates that no 
node-factory (jxpath terminology) is available (to the jxpath context) 
to create new 'nodes' in the backend (i.e. a bigger array in the bean, 
or additional objects to add to the list).

I assume the multi-value binding was only tested versus XML backends 
since those have by default a node-generation factory installed (and 
thus the problem never occurs)

Towards javaBean backends this reveals that the the multi-value lacks 
the feature of declaring such a factory (to compare: this is what the 
 inside the repeater binding is for)

IMHO multi-value binding code looks like an early clone of the 
simple-repeater binding.  This issue kinda re-affirms my feeling that 
there is no reason to maintain this multi-value-binding in the future.


[2 - on the confusing naming of the bindings]
Of course this leads me to some other observation: the names of the 
bindings are way too look-alike to the names of the widgets!

Because of this the misconception has grown that the binding file is a 
duplicate of your definition file that needs to allocate the matching 
binding-component to the matching widget. THIS IS NOT THE CASE. (see 
e.g. the last binding-sample '03aggregate': there an aggregate widget 
gets bind using both the aggregate-binding and the value-binding: that 
just works, and it's not a hack, nor an after-thought.)

In the form-definition one needs to select those widgets that build up 
the 'form-model' that is capable of supporting the end-user-interaction 
(ie both html form generation and request parameter processing) and 
validating/datatyping the entered values.

In the binding definition there is a different goal/concern: there one 
needs to select not a (passive) model, but an active 'strategy' or 
process that describes how you want to let load/save of data to happen.

Since that strategy mostly matches the actual capabilities of the 
widgets we have ended up here: having (mostly) matching names between 
the chosen widgets and the bindings: but this is a consequence, and as 
pointed out is often misleading our users.

With the above observation we could argue if we need to reconsider 
(naming and structure) of our binding components (just one thing more to

reconsider about cforms it seems :-))


comments welcome.

HTH,
-marc=
-- 
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblo

Re: Repository support for property queries (DASL?)

[Rolf Kulemann]

On Wed, 2004-04-14 at 09:04, Guido Casper wrote:
> ...
> One point of the Repository interface is to find a common way to do 
> simple things and to be portable across repositories with that. And 
> there is no way for searching to be portable across repositories (as 
> long as they don't implement all a common QL syntax and dialekt like 
> JCRQL wants to achieve IIUC).

As Stefano said, the jcr spec. sais that a rep. MUST implement one of
two QLs...(or so)

Ok. That sounds for me one could use the repository to do simple work
against a repository. If I have a more heavy weight application i.e. a
complete cms, one should use sth. like jcr/slide API directly, because
of (transactions and) searching ?

And if using jcr, we are still not portable since there is no "standard"
QL which all reps. MUST implement.

So, without offending anybody or anything: The cocoon reps. will stay
lightweight for quite some more time. Thus if the lenya people want to
go for a repository, we should use slide or wait for jcr-ref-impl since
we have more than "leightweight" requirements.

Stefano said the slidejcr stuff will be out in 2-4 weeks. I hope I will
be lucky.

> 
> So what you might want to do is to create a DASL searcher (like the 
> DASLTransformer?).

I do that, and it works quite fine, but webdav or better APIs like
org.apache.webdavlib are lacking transactions. I can workaround it a bit
with locking everything I need before I start to act on resourcesbut
that is not a long term solution.

-- 
Regards,

Rolf Kulemann

Re: GroovyMarkup syntax works!

[Bertrand Delacretaz]

I've just commited a GroovyMarkup [1] generator sample in the BSF 
block...
Forgot to mention that with the current ScriptGenerator, Groovy scripts 
are interpreted for each request.

There are much better ways to precompile stuff, but it's a start. We'll 
probably need a specialized Groovy block to be more efficient, 
bypassing the BSF.

-Bertrand

GroovyMarkup syntax works!

[Bertrand Delacretaz]

I've just commited a GroovyMarkup [1] generator sample in the BSF 
block, allowing the ScriptGenerator to use syntax like this:

xml.page() {
content() {
section() {
title("GroovyMarkup test")
p("Look ma, no angle brackets!")

ul() {
for(i in 1..5) {
li("This is item " + i)
}
}
   }
}
}
Thanks to James Strachan who very quickly fixed a problem in Groovy's 
SAXBuilder. I've committed a snapshot of the Groovy jar with the fix, 
this will have to be replaced with the next release when it's 
available.

Next step would be to allow the (way cool) Groovy Sql syntax [2] to be 
used for database queries. It should be easy to implement, by making a 
ConnectionProvider available to the scripts so that a groovy.sql.Sql 
object can be created to use Connections from the Cocoon pool (I'm 
thinking of having the ScriptGenerator release them to keep scripts 
simple).

I won't have time to work on it right now, so if someone wants to jump 
in...

-Bertrand

[1] http://groovy.codehaus.org/markup.html
[2] http://groovy.codehaus.org/sql.html

Re: Something about a new core?

[Berin Loritsch]

Geoff Howard wrote:
Berin Loritsch wrote:

I have been following the (un)checked exception dialog because I feel 
that it is the easiest/best place for me to get back in the swing of 
things with Cocoon.  I saw a couple comments about a new core for 
Cocoon, and I was wondering if someone could throw a couple links my 
way for more information.


http://cvs.apache.org/viewcvs.cgi/cocoon-2.2/src/kernel/org/apache/cocoon/kernel/ 

http://marc.theaimsgroup.com/?t=10800483371&r=1&w=2 (original RT)
http://marc.theaimsgroup.com/?t=10807293574&r=1&w=2 (first landing 
in cvs)

Misc:
http://marc.theaimsgroup.com/?t=10807269265&r=1&w=2 (source resolving)
http://marc.theaimsgroup.com/?t=10815217281&r=1&w=2 (hotswapability)
http://marc.theaimsgroup.com/?t=10811716734&r=1&w=2 (component devel)
http://marc.theaimsgroup.com/?t=10807314225&r=1&w=2 (comments on cvs)
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108081251820893&w=2
Mother Load:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=kernel&q=b 
(search on marc archives for "kernel")

HTH,

Geoff



Thank you for the reading material.  I have just finished the thread on
the RT.  I know it's all academic at this point, but I must say I am in
agreement--and I am glad we didn't go with JMX *as* the core of Cocoon.
Still have a lot more to read up on, but I will get there.

SAX event stream bug under load?

[Andrzej Jan Taramina]

We've run into a situation using Cocoon 2.1.4, where under load, sometimes we 
seem to get wires crossed and sax event streams get mixed up between 
different user sessions.

Any known bugs/fixes in this area?

Thanks!

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

Re: Something about a new core?

[Geoff Howard]

Berin Loritsch wrote:
I have been following the (un)checked exception dialog because I feel 
that it is the easiest/best place for me to get back in the swing of 
things with Cocoon.  I saw a couple comments about a new core for 
Cocoon, and I was wondering if someone could throw a couple links my way 
for more information.
http://cvs.apache.org/viewcvs.cgi/cocoon-2.2/src/kernel/org/apache/cocoon/kernel/

http://marc.theaimsgroup.com/?t=10800483371&r=1&w=2 (original RT)
http://marc.theaimsgroup.com/?t=10807293574&r=1&w=2 (first landing in cvs)
Misc:
http://marc.theaimsgroup.com/?t=10807269265&r=1&w=2 (source resolving)
http://marc.theaimsgroup.com/?t=10815217281&r=1&w=2 (hotswapability)
http://marc.theaimsgroup.com/?t=10811716734&r=1&w=2 (component devel)
http://marc.theaimsgroup.com/?t=10807314225&r=1&w=2 (comments on cvs)
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108081251820893&w=2
Mother Load:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=kernel&q=b (search on 
marc archives for "kernel")

HTH,

Geoff

RE: [forms] recursive event loops

[Leo Sutic]

UnrealScript solves this another way:

http://unreal.epicgames.com/UnrealScript.htm:
Singular: The "singular" keyword, which appears immediately 
before a function declaration, prevents a function from 
calling itself recursively. The rule is this: If a certain 
actor is already in the middle of a singular function, any 
subsequent calls to singular functions will be skipped over. 
This is useful in avoiding infinite-recursive bugs in some 
cases. For example, if you try to move an actor inside of 
your "Bump" function, there is a good chance that the actor 
will bump into another actor during its move, resulting in 
another call to the "Bump" function, and so on. You should 
be very careful in avoiding such behaviour, but if you can't 
write code with complete confidence that you're avoiding 
such potential recursive situations, use the "singular" 
keyword.

Disclaimer: I can't write UnrealScript to save my life, so I
don't know how useful this is in reality.

/LS

> From: Bruno Dumon [mailto:[EMAIL PROTECTED] 

Re: [forms] recursive event loops

[Bruno Dumon]

On Thu, 2004-04-15 at 15:32, Berin Loritsch wrote:
> Berin Loritsch wrote:
> 
> > Bruno Dumon wrote:
> > 
> >> I noticed that when I do setValue on a widget in the event handler of
> >> that widget, that CForms goes into an endless loop.
> >>
> >> It would be easy to disable adding new events during event processing,
> >> but I saw the following comment at Form.fireWidgetEvents:
> >> /**
> >>  * Fire the widget events that have been queued. Note that event
> >>  * handling can fire new events.
> >>  */
> >>
> >> so it seems this behaviour is on purpose. Do we want to keep it that
> >> way, or has anyone other suggestions on how to prevent the endless loop?
> >>
> > 
> > Events are a powerful feature, which means it is just as easy to abuse 
> > it as it is to use it.  I have some general guidelines that I assembled 
> > from working on Swing based applications which I have posted over here:
> > 
> > http://s94077374.onlinehome.us/modules/news/article.php?storyid=12
> > 
> > Please be patient, my site seems to be going up and down lately, and I 
> > am not sure why.
> 
> 
> Oops, try this instead:
> 
> http://d-haven.org/modules/news/article.php?storyid=12

thanks.

Made me think I should solve my problem in a different way (not in an
event listener).

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: Something about a new core?

[Berin Loritsch]

Carsten Ziegeler wrote:

Berin Loritsch wrote: 

Also, I do recommend the following article I found linked 
from Carsten Zeigler's blog: 
http://www.martinfowler.com/ieeeSoftware/continuousDesign.pdf

Start simple, stay simple as I continuously harp on my essays 
at d-haven.org.  As always easier said than done.  I am 
constantly learning more and finding I know less.  :)  
Nevertheless, as the blocks and other things are developed 
and refined the continuous design approach does work wonders. 
Yes, I can't agree more (although my last name is "Ziegeler" :) )
Sorry.  I guess that's what happens when you operate from memory...

Re: [forms] recursive event loops

[Berin Loritsch]

Berin Loritsch wrote:

Bruno Dumon wrote:

I noticed that when I do setValue on a widget in the event handler of
that widget, that CForms goes into an endless loop.
It would be easy to disable adding new events during event processing,
but I saw the following comment at Form.fireWidgetEvents:
/**
 * Fire the widget events that have been queued. Note that event
 * handling can fire new events.
 */
so it seems this behaviour is on purpose. Do we want to keep it that
way, or has anyone other suggestions on how to prevent the endless loop?
Events are a powerful feature, which means it is just as easy to abuse 
it as it is to use it.  I have some general guidelines that I assembled 
from working on Swing based applications which I have posted over here:

http://s94077374.onlinehome.us/modules/news/article.php?storyid=12

Please be patient, my site seems to be going up and down lately, and I 
am not sure why.


Oops, try this instead:

http://d-haven.org/modules/news/article.php?storyid=12

Re: [forms] recursive event loops

[Berin Loritsch]

Bruno Dumon wrote:

I noticed that when I do setValue on a widget in the event handler of
that widget, that CForms goes into an endless loop.
It would be easy to disable adding new events during event processing,
but I saw the following comment at Form.fireWidgetEvents:
/**
 * Fire the widget events that have been queued. Note that event
 * handling can fire new events.
 */
so it seems this behaviour is on purpose. Do we want to keep it that
way, or has anyone other suggestions on how to prevent the endless loop?
Events are a powerful feature, which means it is just as easy to abuse 
it as it is to use it.  I have some general guidelines that I assembled 
from working on Swing based applications which I have posted over here:

http://s94077374.onlinehome.us/modules/news/article.php?storyid=12

Please be patient, my site seems to be going up and down lately, and I 
am not sure why.

RE: Something about a new core?

[Carsten Ziegeler]

Berin Loritsch wrote: 
> 
> Also, I do recommend the following article I found linked 
> from Carsten Zeigler's blog: 
> http://www.martinfowler.com/ieeeSoftware/continuousDesign.pdf
> 
> Start simple, stay simple as I continuously harp on my essays 
> at d-haven.org.  As always easier said than done.  I am 
> constantly learning more and finding I know less.  :)  
> Nevertheless, as the blocks and other things are developed 
> and refined the continuous design approach does work wonders. 
Yes, I can't agree more (although my last name is "Ziegeler" :) )

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/

[forms] recursive event loops

[Bruno Dumon]

I noticed that when I do setValue on a widget in the event handler of
that widget, that CForms goes into an endless loop.

It would be easy to disable adding new events during event processing,
but I saw the following comment at Form.fireWidgetEvents:
/**
 * Fire the widget events that have been queued. Note that event
 * handling can fire new events.
 */

so it seems this behaviour is on purpose. Do we want to keep it that
way, or has anyone other suggestions on how to prevent the endless loop?

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Something about a new core?

[Berin Loritsch]

I have been following the (un)checked exception dialog because I feel 
that it is the easiest/best place for me to get back in the swing of 
things with Cocoon.  I saw a couple comments about a new core for 
Cocoon, and I was wondering if someone could throw a couple links my way 
for more information.

Also, I do recommend the following article I found linked from Carsten 
Zeigler's blog: 
http://www.martinfowler.com/ieeeSoftware/continuousDesign.pdf

Start simple, stay simple as I continuously harp on my essays at 
d-haven.org.  As always easier said than done.  I am constantly learning 
more and finding I know less.  :)  Nevertheless, as the blocks and other 
things are developed and refined the continuous design approach does 
work wonders.  It can even provide some natural ways to find the balance 
between checked and unchecked exceptions.

Re: [RT] Checked exceptions considered harmful

[Vadim Gritsenko]

Leon Widdershoven wrote:



Bertrand Delacretaz wrote:

Le 14 avr. 04, à 20:00, Leon Widdershoven a écrit :

...I don't think throws Exception in all declarations is a plus; a 
function which operates on files could have an IOException, a 
function which operates on numbers a NumberException
or something akin; in essence, the root of the expected Exception 
hierarchy (for interfaces and abstratc classes)


I like the idea, similar to what Berin suggests: using base 
exceptions which tell us what the problem is about, without being too 
specific.

-Bertrand

Similar but *not* the same. And it holds only for interfaces. I think the
actual classes should be a bit more specific (not just Exception - 
that doesn't tell anything).

But to give an example, I define a virtual DataSource (not a 
cocoon/avalon one):

interface DataSource {
// ...
public String getData() throws IOException;
}
In does not matter why a datasource could not get the data. Whether
a file is not found, could not be read, a netwerk address is not 
available,
a database does not exist, an SQLException occurred - for this function
it only matters that no input could be obtained.

An implementation should then of course re-wrap the exception to an IO
exception. With an appropriate message (I think cocoon has good exception
messages btw).
I think it is important in such a case to be generic since it is 
extremely hard for software to automatically correct any problem in 
such a case.
You might want to access a backup data source, but for that you only 
need to
know that the operation has failed. Not exactly why (it should be in the
logs though).


Let me correct you. In this particular example you just gave, it *is* 
important to know some details. If the FileNotFoundException happened, 
generally, it is not wise to re-try on backup data source. And, if data 
source is remote, in case of SocketException you can just re-try (after 
short sleep interval).

Vadim


If you/the software knew a file does not exist, could it
automatically create one with the requested data? Normally not - if you
had the data you would not need to ask it.
That is why I think overly specific exceptions are not always the best
way - the exceptions you specify as a library developer should not just
image the exceptions thrown by used functions, but be of use to the 
calling
developer. And (s)he want's to know whether the action has failed.

Leon

DO NOT REPLY [Bug 28387] - Portal: HTMLEventLinkTransformer eats form attributes

[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=28387

Portal: HTMLEventLinkTransformer eats form attributes

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2004-04-15 10:12 ---
Works for me.

DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception

[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=27249

You cannot lookup components on a disposed ComponentLocator exception





--- Additional Comments From [EMAIL PROTECTED]  2004-04-15 09:21 ---
Just guessing, could it be that this is related to the delayed checking of the 
sitemap? The DelayedRefreshSourceWrapper is used and if you do a CVS commit 
this takes more time perhaps than editing the file by hand?
If you can reproduce the problem, you could try it by removing 
DelayedRefreshSourceWrapper from the DefaultTreeBuilder and use the Source 
directly.
(PS: The delay time is 1 sec, so if everything is ok, this can't be the reason, 
but who knows?)

Re: [cforms] Moving out of

[Bruno Dumon]

On Thu, 2004-04-15 at 00:13, Sylvain Wallez wrote:
> Bruno Dumon wrote:
> 
> >On Wed, 2004-04-14 at 11:40, Sylvain Wallez wrote:
> >  
> >
> >>Hi all,
> >>
> >>A few weeks ago, I generalized validation to every widgets, and not only 
> >>fields. The main visible result of this is that  is now a 
> >>direct child of  (or other widget-defining element), and no 
> >>more a child of .
> >>
> >>Validation as a child of  is still supported as a legacy 
> >>behaviour, but I would like to remove it to drive people towards the new 
> >>generalized validation. My plan to ease the migration is to raise a 
> >>meaningful exception ("fd:validation has moved") whenever we encounter a 
> >>fd:validation inside a fd:datatype.
> >>
> >>
> >
> >Just been looking a bit at this...
> >
> >For the validation rules associated with datatypes, it is checked that
> >the validation rule is compatible with the datatype (i.e. can handle the
> >kind of objects that the datatype represents). Does such a check still
> >happen? Or will this give errors at runtime?
> >  
> >
> 
> Damn, missed that one...
> 
> The problem with the generalized validation is that it is erm... 
> generalized. And as such validation rules can be applied to any kind of 
> widget, including those that don't have a value.
> 
> A solution is to generalize this check also, by introducing a 
> ValidationRule.canValidate(WidgetDefinition) which, in the case of typed 
> validators, will get the widget definition's datatype to perform today's 
> check.

sounds good.

While we're at it, I propose we also move the package
o.a.c.forms.datatype.validationruleimpl to o.a.c.forms.validators

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

DO NOT REPLY [Bug 27249] - You cannot lookup components on a disposed ComponentLocator exception

[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=27249

You cannot lookup components on a disposed ComponentLocator exception





--- Additional Comments From [EMAIL PROTECTED]  2004-04-15 08:43 ---
I'm experiencing the problem, too (cocoon 2.1.4). In my setup, it has certainly
nothing to do with CVS (though the sitemap has a CVS Id). I have an EAR that
deploys fine using JBoss-3.2.3 on several machines (both Windows and Linux
types). There is one machine, however, where everything is -- to the best of my
knowledge -- configured in the same way as on all the other machines, and there
I get the error.

Adding e.g. a space to the sitemap helps only temporarily. The applictaion uses
the sitemap to generate a frameset and each frame then uses the sitemap to get
its contents. The frameset is always generated, the frames aren't. When I add
the space to the sitemap, I can reload one frame. The second fails again (quite
a tedious way to get your GUI ;-) ).

DO NOT REPLY [Bug 28387] - Portal: HTMLEventLinkTransformer eats form attributes

[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=28387

Portal: HTMLEventLinkTransformer eats form attributes

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-04-15 07:52 ---
I applied a slightly changed version - please cross-check and close (or reopen) 
the  bug.
Thanks!

Re: [RT] Checked exceptions considered harmful

[Leon Widdershoven]

Bertrand Delacretaz wrote:
Le 14 avr. 04, à 20:00, Leon Widdershoven a écrit :

...I don't think throws Exception in all declarations is a plus; a 
function which operates on files could have an IOException, a function 
which operates on numbers a NumberException
or something akin; in essence, the root of the expected Exception 
hierarchy (for interfaces and abstratc classes)


I like the idea, similar to what Berin suggests: using base exceptions 
which tell us what the problem is about, without being too specific.

-Bertrand

Similar but *not* the same. And it holds only for interfaces. I think the
actual classes should be a bit more specific (not just Exception - that 
doesn't tell anything).

But to give an example, I define a virtual DataSource (not a cocoon/avalon one):

interface DataSource {
// ...
public String getData() throws IOException;
}
In does not matter why a datasource could not get the data. Whether
a file is not found, could not be read, a netwerk address is not available,
a database does not exist, an SQLException occurred - for this function
it only matters that no input could be obtained.
An implementation should then of course re-wrap the exception to an IO
exception. With an appropriate message (I think cocoon has good exception
messages btw).
I think it is important in such a case to be generic since it is extremely 
hard for software to automatically correct any problem in such a case.
You might want to access a backup data source, but for that you only need to
know that the operation has failed. Not exactly why (it should be in the
logs though). If you/the software knew a file does not exist, could it
automatically create one with the requested data? Normally not - if you
had the data you would not need to ask it.

That is why I think overly specific exceptions are not always the best
way - the exceptions you specify as a library developer should not just
image the exceptions thrown by used functions, but be of use to the calling
developer. And (s)he want's to know whether the action has failed.
Leon