Re: CForms Summer of Code project

[Reinhard Poetz]

Sylvain Wallez wrote:

I also want a second person as official mentor as I will be offline 
for some weeks over the summer. Anybdoy volunteering?
 
Me, me :-)


Thanks Sylvain, I've just added your name to the Wiki page.

--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc






___ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

Re: Sitemap: flow and interpreters

[Reinhard Poetz]

Carsten Ziegeler wrote:

While inspecting the current sitemap (tree builder) code for flow,
I'm wondering about the support for different languages.

The basic question first: do we want to support more than one flow
language per sitemap?

If yes, imho this isn't supported yet. It's possible to register
scripts for different interpreters in a single sitemap. But as
each flow node (containing the scripts) registeres itself at
the tree processor and as the treeprocessor uses a simple map
to store them, the last node wins. In addition there isn't a way
to tell the call function node which language it should use.

I think we should either allow only one script language per sitemap
or we should fix the current code. I prefer the second solution.

WDYT?


You're right that only one flow language can be used within one sitemap. 
Additionally to your reasons, there are two others:


 - we need access to the flow controller of a sitemap
   (to make e.g. Flowscript calls like
var x = cocoon.blocks.blockXYZ.myFunc()
possible)
 - IIRC there is some sort of hack to identify the called method
   in the JavaInterpreter.callFunction() method. If two registered
   Javaflow classes have equally named methods, you can't use
   both of them in your sitemap as one of them (I think the first)
   is used

--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc






___ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

Re: [VOTE] Document Editors, and a new Committer

[Antonio Gallardo]

On Jue, 9 de Junio de 2005, 4:52, Upayavira dijo:
> As granting committership requires a vote, please cast your votes now:
>
> [ ] Helma Van Der Linden as a Cocoon committer

+1, Welcome Helma! :-)

Best Regards,

Antonio Gallardo

Re: Build Cocoon 2.1.7

[Antonio Gallardo]

Hi Elvira:

Wich cocoon distro are you deployed? [zip or tar.gz]
Based on the errors I guess you are using a cocoon zip distro. Since you
use Debian, please try the tar.gz

Best Regards,

Antonio Gallardo


On Vie, 10 de Junio de 2005, 11:29, [EMAIL PROTECTED] dijo:
>
> Hi again, :(
>
> ok, with the solution that i responsed in my previous mail i can build
> correctly cocoon but now i have the next fail when i do
> http://localhost:8080/cocoon
>
> *excepción*
>
> javax.servlet.ServletException: Servlet.init() para servlet Cocoon lanzó
> excepción
>   
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>   
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>   
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
>   
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:738)
>   
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
>   
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>   
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>   java.lang.Thread.run(Thread.java:595)
>
> *causa raíz*
>
> java.lang.NullPointerException
>   
> org.apache.cocoon.servlet.multipart.RequestFactory.(RequestFactory.java:61)
>   org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:473)
>   
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>   
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>   
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
>   
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:738)
>   
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
>   
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>   
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>
> I use Tomcat 5.
>
> Any idea?
>
> Best desires
>
>   java.lang.Thread.run(Thread.java:595)
>
>
>
>
>
> [EMAIL PROTECTED] escribió:
>
>> Hello again,
>>
>> I ask and i reply me. XD
>>
>> The solution is to create a empty folder in src/blocks/stx/java
>>
>> Best regards
>>
>>
>>
>> [EMAIL PROTECTED] escribió:
>>
>>> Hello everybody,
>>>
>>> I am having problems to build the src version of cocoon-2.1.7.
>>>
>>> I am excluding the "stx" block with my local.block.properties.
>>> excluded:
>>>  NOTICE 
>>> ...
>>> Block 'stx' is excluded from the build.
>>> ...
>>> 
>>>
>>>
>>> ...but later on:
>>>
>>> BUILD FAILED
>>> /mnt/data/home/usuario/Elvira/Binarios/cocoon-2.1.7/tools/targets/docs-build.xml:264:
>>> The following error occurred while executing this line:
>>> /mnt/data/home/usuario/Elvira/Binarios/cocoon-2.1.7/build/cocoon-2.1.7/temp/blocks-build.xml:619:
>>> /mnt/data/home/usuario/Elvira/Binarios/cocoon-2.1.7/src/blocks/stx/java
>>> not found.
>>>
>>>
>>> Anybody knows what is going on and how to fix that?
>>>
>>> salu2
>>>
>>>
>>> -- Elvira Nieto Carretero
>>>   Isotrol, S.A.
>>>
>>> -
>>>  Isotrol, S.A.
>>>  Edificio Innova
>>>  Avda. de la Innovacion, 1, 3ª planta
>>>  41020 SEVILLA
>>>  Tel.: 955 036 800 Fax: 955 036 849
>>>  Correo-e: [EMAIL PROTECTED]
>>>
>>>
>>
>>
>> -- Elvira Nieto Carretero
>>   Isotrol, S.A.
>>
>> -
>>  Isotrol, S.A.
>>  Edificio Innova
>>  Avda. de la Innovacion, 1, 3ª planta
>>  41020 SEVILLA
>>  Tel.: 955 036 800 Fax: 955 036 849
>>  Correo-e: [EMAIL PROTECTED]
>>
>>
>
>
> --
>Elvira Nieto Carretero
>Consultora y Analista de Portales de Internet
>Isotrol, S.A.
>
> -
>   Isotrol, S.A.
>   Edificio Innova
>   Avda. de la Innovacion, 1, 3ª planta
>   41020 SEVILLA
>   Tel.: 955 036 800 Fax: 955 036 849
>   Correo-e: [EMAIL PROTECTED]
>
>
>

Re: [Daisy/Docs] Styling conventions

[Glen Ezkovich]

On Jun 10, 2005, at 3:38 PM, Ross Gardler wrote:


Leszek Gawron wrote:


Linden H van der (MI) wrote:



...


It would be the best if you provided your guideline as a template  
page YourPageShouldLookLikeThis.




It would be even better if you defined classes for the different  
style elements you want and disable the ability to arbitrarily use  
 and  for example.
The htmlArea plugin can be customised so that the drop down menu  
has things like:


Instruction
Code
screenOutput
Command

etc.



I'm not sure removing the ability use these tags is wise. While we  
need conventions for our documentation we do need to allow for in- 
lining italics and bold so that an author can emphasize a point. I  
think the advantage to the specialized tags is that we can do thing  
that really make instructions, code, text, expected output, etc.  
stand out. Indenting and using different background colors or boxes  
can do wonders.





(NB this is something I need to do for my own work soon, the Daisy  
team have already pointed me at how to do it). I'll write up a  
document for them when I've figured out the rest. May be a month or  
so before I get time though.


You shuold also look into created specific document types for  
things like FAQ's, HowTo's user documentation etc. I have a set of  
document types that I use like this. It makes for much more  
structure to your documents, which ultimately makes them more useful.


Agreed. Templates will make it easier for new documentarians. One of  
the things I've done is define document types and created forms for  
their input. Obviously a next step. It doesn't fit every case but  
certainly faqs can be broken into questions and answers.



Glen Ezkovich
HardBop Consulting
glen at hard-bop.com



A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to  
worry about answers."

- Thomas Pynchon Gravity's Rainbow

Re: compiling a custom transformer

[Ralph Goers]

I believe I just saw something today in Daisy that documented that and I 
think it was copied from the Wiki. I'd look there.


Ralph

Lars Huttar wrote:


Ralph Goers wrote:

I use maven to do my builds. The jars are all in our local 
repository. These are the dependencies I have in my project.xml to 
compile:

...



Thanks for your reply.

I haven't used Maven, and I'm reluctant to add another third-party 
tool to our process.


Is there a way to compile these extensions just using the Cocoon (Ant) 
build script? E.g. by adding a block?


Thanks,
Lars

Re: [Daisy/Docs] Styling conventions

[Ross Gardler]

Linden H van der (MI) wrote:
It would be even better if you defined classes for the 
different style 
elements you want and disable the ability to arbitrarily use  and 
 for example.



This is already taken care of in Daisy by the htmlArea plugin and
Daisy's HTMLCleaner


The HTMLCleaner is great, but in my view it doesn't go far enough 
consider this:


It is really important.

It is really important.

It is really important.

All legal, all inconsistent. At least one not in line with the style 
guide you suggest.


Still, it's the least important point from my mail.

The htmlArea plugin can be customised so that the drop down menu has 
things like:


Instruction
Code
screenOutput
Command



This is a good idea.


You shuold also look into created specific document types for things 
like FAQ's, HowTo's user documentation etc. I have a set of document 
types that I use like this. It makes for much more structure to your 
documents, which ultimately makes them more useful.



Yes. I've been thinking about that. Even labeling documents with flags
like 'tutorial' 'beginner' etc. would be sufficient for now.
I don't have the privileges to set it up, so I'll bug Steven about it
when we figure out what should be done. ;-)


Anyone with admin rights can set up the necesary configuration. So 
perhaps we need to decide who should have admin rights (I'd suggest 
committers who also want to be editors).


For the flags part, there is a multivalued field. You can add keywords 
(such as 'user', 'developer', 'beginner', 'advanced' etc.) and assign 
them to each document. You can then create index pages using the query 
language by searching on the keywords.


If you have sensible document types you can then create, for example, an 
index of tutorials for advanced developers with a simple little query.


I wouldn't use the keywords approach for identifying the diffferent 
document types, because the advantage of document types is that you can 
have different parts for different types of document. e.g. a FAQ just 
has a question (the document title), and an answer, but a HowTo has an 
abstract, a pre-requisites, a body, a summary a further reading section.


The advantage will be obvious, I am sure. You can do things like crete a 
"trail" through the How-To's be parsing all the entries in the 
pre-requisites section, or you can provide a "reminder sheet" that just 
has the summaries from all begineer tutorials etc.


This approach is working really well for an internal project here.

Ross

Re: [Daisy/Docs] Styling conventions

[Glen Ezkovich]

I started this a while ago and some of this has been brought up by  
Ross so some is a repeat. The most important thing is that we be  
consistent in style. It will make users lives much easier if we have  
a single set of conventions.


On Jun 10, 2005, at 3:28 AM, Linden H van der (MI) wrote:


To all document editors,

Seeing Mark's work and my own I decided that we best set some basic
rules for writing the documentation and using particular styling. This
improves a consistent look and prevents tedious cleanup at a later
stage.


This is essential in the finished product. Tedious cleanup is to be  
avoided. While I know its not possible now, we need to take advantage  
of Cocoon's transformation abilities. Right now I am concentrating on  
content. In the future I think it would be wise to come up with a set  
of tags for the documentation such as



...
,
...

etc.

This would separate the content from the presentation, making the  
documentation process about documentation. In the future we would  
just need to change the xsl or css to change the presentation.




This is what I propose (and I know _I_ haven't been consistent):

- when describing what to do, mark the text that is shown on screen  
with

italics. Example:

Choose Menu > Option
Select the tab SomeTab


I prefer bold, but I speak italics as well. ;-)



- when describing what to enter, put the text in a separate  
'Formatted'

() paragraph. Example:

Now enter:

Some command here


see above. While this is necessary right now, it will present  
problems keeping things consistent. One of the many problems that are  
encountered is the number of spaces to indent the instructions, or  
wether they should be indented at all.


If possible rewrite the sentence to something like "instructions":  
"text

to enter", unless that becomes very awkward. In that case put the text
to be entered in bold or italics (let's decide which one).


I would change the font. Use .



- I prefer to mark environment variables and similar things with bold,
although I haven't yet decided where to draw the line. Text should be
readable, not colorful. ;-)

- remove any  tags within a  list item

- for now: let's start marking section headers with 'Heading  
1' (),

subsections with 'Heading 2' () and so on, irrelevant of the
importance of the section compared to other documents. I know I  
started

with  sometimes.


Another use case for using tags. I've had this problem on several  
sites. We wound up using just  tags that were transformed to the  
appropriate xhtml tag based on wether they were contained with in a  
page, section or subsection tag.




Note: I assume that setting this styling is done through the HTMLarea
editor, not directly in the textarea editor.

WDYT?


This is the only way to go at the moment. Long term, I think we need  
to define the elements of documentation, create tags and let Cocoon  
transform them to the appropriate xhtml. After all isn't Coocon about  
separating content from presentation?




Glen Ezkovich
HardBop Consulting
glen at hard-bop.com



A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to  
worry about answers."

- Thomas Pynchon Gravity's Rainbow

Re: compiling a custom transformer

[Lars Huttar]

Ralph Goers wrote:

I use maven to do my builds. The jars are all in our local repository. 
These are the dependencies I have in my project.xml to compile:

...


Thanks for your reply.

I haven't used Maven, and I'm reluctant to add another third-party tool 
to our process.


Is there a way to compile these extensions just using the Cocoon (Ant) 
build script? E.g. by adding a block?


Thanks,
Lars

RE: [Docs] Refactoring, porting Wiki content, and evaluating Daisy

[Linden H van der (MI)]

> Another question: how do include anchors within pages? Should I do it 
> manually with the HTML view?

No idea, do check it as I'm not sure it'll pass the HTMLCleaner config.

Bye, Helma

RE: [VOTE] Document Editors, and a new Committer

[Nathaniel Alfred]

>-Original Message-
>From: Upayavira [mailto:[EMAIL PROTECTED]
>Sent: Donnerstag, 9. Juni 2005 11:52
>To: dev@cocoon.apache.org
>Subject: [VOTE] Document Editors, and a new Committer

>On this basis, I'd like to propose Helma Van Der Linden as a Cocoon 
>committer, and thus our first 'publisher'. She has been participating 
>regularly in our community, and has shown a quiet but steady interest in 
>helping with our documentation, as well as an increasingly clear 
>understanding of how our community works.
>
>As granting committership requires a vote, please cast your votes now:
>
>[ ] Helma Van Der Linden as a Cocoon committer

Sure +1 and welcome.

Cheers, Alfred.
 
 
This message is for the named person's use only. It may contain confidential, 
proprietary or legally privileged information. No confidentiality or privilege 
is waived or lost by any mistransmission. If you receive this message in error, 
please notify the sender urgently and then immediately delete the message and 
any copies of it from your system. Please also immediately destroy any 
hardcopies of the message. You must not, directly or indirectly, use, disclose, 
distribute, print, or copy any part of this message if you are not the intended 
recipient. The sender’s company reserves the right to monitor all e-mail 
communications through their networks. Any views expressed in this message are 
those of the individual sender, except where the message states otherwise and 
the sender is authorised to state them to be the views of the sender’s 
company.

RE: [Daisy/Docs] Styling conventions

[Linden H van der (MI)]

> It would be the best if you provided your guideline as a 
> template page 
> YourPageShouldLookLikeThis.

Good idea.

> OT: Suppose I'd like to review some documents that have not been 
> published yet. Is there a special query for that?

Yes, I don't have it from the top of my head, but if you select "query"
in the gray bar you get a page where you can enter queries. On the right
is a link to 'common queries'. One of those is a list of documents which
have a latest version that is not published.

HTH.

Bye, Helma

RE: [Daisy/Docs] Styling conventions

[Linden H van der (MI)]

> It would be even better if you defined classes for the 
> different style 
> elements you want and disable the ability to arbitrarily use  and 
>  for example.

This is already taken care of in Daisy by the htmlArea plugin and
Daisy's HTMLCleaner

> The htmlArea plugin can be customised so that the drop down menu has 
> things like:
> 
> Instruction
> Code
> screenOutput
> Command

This is a good idea.

> You shuold also look into created specific document types for things 
> like FAQ's, HowTo's user documentation etc. I have a set of document 
> types that I use like this. It makes for much more structure to your 
> documents, which ultimately makes them more useful.

Yes. I've been thinking about that. Even labeling documents with flags
like 'tutorial' 'beginner' etc. would be sufficient for now.
I don't have the privileges to set it up, so I'll bug Steven about it
when we figure out what should be done. ;-)

Bye, Helma

Re: [Daisy/Docs] Styling conventions

[Ross Gardler]

Leszek Gawron wrote:

Linden H van der (MI) wrote:


...

It would be the best if you provided your guideline as a template page 
YourPageShouldLookLikeThis.


It would be even better if you defined classes for the different style 
elements you want and disable the ability to arbitrarily use  and 
 for example.


The htmlArea plugin can be customised so that the drop down menu has 
things like:


Instruction
Code
screenOutput
Command

etc.

(NB this is something I need to do for my own work soon, the Daisy team 
have already pointed me at how to do it). I'll write up a document for 
them when I've figured out the rest. May be a month or so before I get 
time though.


You shuold also look into created specific document types for things 
like FAQ's, HowTo's user documentation etc. I have a set of document 
types that I use like this. It makes for much more structure to your 
documents, which ultimately makes them more useful.


Ross

RE: Why does XSPMarkupLanguage wrap text in xsp:text?

[Nathaniel Alfred]

>-Original Message-
>From: Jochen Kuhnle [mailto:[EMAIL PROTECTED]
>Sent: Mittwoch, 8. Juni 2005 19:04
>To: dev@cocoon.apache.org
>Subject: Re: Why does XSPMarkupLanguage wrap text in xsp:text?

>Hope I'm not too annoying on this issue, but on further work on logic 
>sheets, I believe the auto-wrapping is not only complicating 
>things a bit, it is actually introducing problems.
>
>ContentHandler.characters specification [1] says that the character data 
>can be fed in chunks, so autowrapping text ".a..b..c..d." ('.' stands for 
>space) might not rsult in .a..b..c..d., but in 
>.a..b..c..d or some other 
>"partitioning". It actually gets chunked in the current implementation if 
>there are newlines in the text.
>
>Now consider e.g. the python xsp.xsl, which has a "space='strip'" option, 
>where the template for xsp:text does a normalize-space(). So partitioning 
>.a..b..c..d. results in "a.b.c.d", while partitioning 
>.a..b..c..d. 
>results in "a.bc.d". 
>
>I would think there are some more side effects like this somewhere, so I 
>would suggest either fixing the PreProcessFilter, so it fixes chunking, or 
>remove it alltogether.
>
>Regards,
>Jochen

I can only guess that the autowrapping was intended to allow logicsheets
match="xsp:text/text()" for text content and match="text()" for program
code.  It remains a mystery to me why none of the builtin logicsheets 
actually uses this.

Removing the autowrapping may break a few custom logicsheets depending
on this, but since it is a rather obscure feature nowhere mentioned in
the user docs, I am +1 for dropping the autowrapping.  Is does indeed
make logicsheet input more predictable.

Cheers, Alfred.
 
 
This message is for the named person's use only. It may contain confidential, 
proprietary or legally privileged information. No confidentiality or privilege 
is waived or lost by any mistransmission. If you receive this message in error, 
please notify the sender urgently and then immediately delete the message and 
any copies of it from your system. Please also immediately destroy any 
hardcopies of the message. You must not, directly or indirectly, use, disclose, 
distribute, print, or copy any part of this message if you are not the intended 
recipient. The sender's company reserves the right to monitor all e-mail 
communications through their networks. Any views expressed in this message are 
those of the individual sender, except where the message states otherwise and 
the sender is authorised to state them to be the views of the sender's company.

Re: [osgi] Package structure

[Bertrand Delacretaz]

Le 10 juin 05, à 18:23, Daniel Fagerstrom a écrit :
...I will be offline the comming week (sailing). Feel free to finish 
the OSGi stuff while I'm away ;)


hmmm...this OSGI stuff is cool, but if we have a choice, I'd rather go 
sailing ;-)


-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Document Editors, and a new Committer

[Upayavira]

Glen Ezkovich wrote:


On Jun 9, 2005, at 4:52 AM, Upayavira wrote:

Also, I'd like to invite both Mark Leicester and Glen Ezkovich to  be 
editors, so that they can get on and do good stuff without  having to 
ask. They have the ideas and enthusiasm, and I'm very  keen to see 
what they can come up with. If they wish to accept this  invitation, 
they can be provided with the necessary accounts.





Gee, I spend one day, just one day, not reading this list and look  what 
happens.

I'd be honored to accept the invitation. I will register straight away.


Your account now has editor privileges.

Upayavira

Re: CForms stabilization tasks (was Re: Marking cforms stable in 2.1.8)

[Leszek Gawron]

Sylvain Wallez wrote:

Paul Crabtree wrote:


Hi, i've just finished quite a large cocoon site using 2.1.7 with
Forms V3. We choose this version for two reasons:

1. At the time i couldnt find much info on the different versions or
why they were there so assumed V3 meant it was more mature and the
latest.
 



Well, yes, the latest, but the youngest and therefore not the more 
mature :-)



2. showForm() in V3 offers the ability to send viewData


V1 does also

and declare a function for execution after the form has been shown 
each time.




V1 does also, allowing two functions to handle the iterative nature of 
showForm: one after the page has been displayed (for cleanup) and one 
when the browser submits the form (for restoring).



V2
allows a function but no viewData and V1 allows viewData but no
function (i think). We therefore felt V3 had a richer, more flexible
JS API and we thought we were going to need the function and viewData
for our project.
 



Ok. So the good news is that V1 does all what you need and more !
IIRC only one implementation handles javascript event handlers 
(form.widget.onValueChanged = function() { } or something ). I do not 
have a cocoon checkout on this station so I cannot check. Is it still so?


--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Daisy/Docs] Styling conventions

[Leszek Gawron]

Linden H van der (MI) wrote:

To all document editors,

Seeing Mark's work and my own I decided that we best set some basic
rules for writing the documentation and using particular styling. This
improves a consistent look and prevents tedious cleanup at a later
stage.

This is what I propose (and I know _I_ haven't been consistent):

- when describing what to do, mark the text that is shown on screen with
italics. Example:

Choose Menu > Option
Select the tab SomeTab

- when describing what to enter, put the text in a separate 'Formatted'
() paragraph. Example:

Now enter: 


Some command here

If possible rewrite the sentence to something like "instructions": "text
to enter", unless that becomes very awkward. In that case put the text
to be entered in bold or italics (let's decide which one).

- I prefer to mark environment variables and similar things with bold,
although I haven't yet decided where to draw the line. Text should be
readable, not colorful. ;-)

- remove any  tags within a  list item 


- for now: let's start marking section headers with 'Heading 1' (),
subsections with 'Heading 2' () and so on, irrelevant of the
importance of the section compared to other documents. I know I started
with  sometimes.

Note: I assume that setting this styling is done through the HTMLarea
editor, not directly in the textarea editor.

WDYT?

Bye, Helma
It would be the best if you provided your guideline as a template page 
YourPageShouldLookLikeThis.


OT: Suppose I'd like to review some documents that have not been 
published yet. Is there a special query for that?


--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65


smime.p7s
Description: S/MIME Cryptographic Signature

[Daisy/Docs] Styling conventions

[Linden H van der (MI)]

To all document editors,

Seeing Mark's work and my own I decided that we best set some basic
rules for writing the documentation and using particular styling. This
improves a consistent look and prevents tedious cleanup at a later
stage.

This is what I propose (and I know _I_ haven't been consistent):

- when describing what to do, mark the text that is shown on screen with
italics. Example:

Choose Menu > Option
Select the tab SomeTab

- when describing what to enter, put the text in a separate 'Formatted'
() paragraph. Example:

Now enter: 

Some command here

If possible rewrite the sentence to something like "instructions": "text
to enter", unless that becomes very awkward. In that case put the text
to be entered in bold or italics (let's decide which one).

- I prefer to mark environment variables and similar things with bold,
although I haven't yet decided where to draw the line. Text should be
readable, not colorful. ;-)

- remove any  tags within a  list item 

- for now: let's start marking section headers with 'Heading 1' (),
subsections with 'Heading 2' () and so on, irrelevant of the
importance of the section compared to other documents. I know I started
with  sometimes.

Note: I assume that setting this styling is done through the HTMLarea
editor, not directly in the textarea editor.

WDYT?

Bye, Helma

Re: [osgi] Package structure

[Vadim Gritsenko]

Bertrand Delacretaz wrote:

Le 7 juin 05, à 23:43, Sylvain Wallez a écrit :


Daniel Fagerstrom wrote:

...So IMO we need a policy for package naming. Is there any "style 
guide" for package names for Eclipse plugins that we can adapt? 
Otherwise using something like:


  org.apache.cocoon.blockname.**



Yep. That's how it's done for Eclipse plugin. Each plugin has a name 
which is unique among all plugin and which is the root package for 
classes contained in the plugin...



Just thinking, because I'm working on a block:

  org.apache.cocoon.blocks.blockname.**

might be better, the blocks prefix makes name clashes less probable.


++1

Vadim

Re: London Users' Group Meeting next Wednesday 15th June

[Andrew Savory]

Hi,

On 9 Jun 2005, at 20:38, Upayavira wrote:

I don't know if we usually book. I think we just turn up and find 
seats. We don't normally have food, just guzzle :-)


We don't book ... it's not really a bookable kind of place (unless of 
course we have hundreds turning up!).


I'll wear a GT2004 t-shirt so those people that haven't met before can 
spot us. They look like this: 
http://www.flickr.com/photos/silent-penguin/815204/



Andrew.

--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/

Re: [VOTE] Document Editors, and a new Committer

[Glen Ezkovich]

On Jun 9, 2005, at 4:52 AM, Upayavira wrote:

Also, I'd like to invite both Mark Leicester and Glen Ezkovich to  
be editors, so that they can get on and do good stuff without  
having to ask. They have the ideas and enthusiasm, and I'm very  
keen to see what they can come up with. If they wish to accept this  
invitation, they can be provided with the necessary accounts.





Gee, I spend one day, just one day, not reading this list and look  
what happens.

I'd be honored to accept the invitation. I will register straight away.


Glen Ezkovich
HardBop Consulting
glen at hard-bop.com



A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to  
worry about answers."

- Thomas Pynchon Gravity's Rainbow

RE: [Docs] Retiring documents w/o approval of publishers? (was: Refactoring, porting Wiki content, and evaluating Daisy)

[Linden H van der (MI)]

> One more thing: I just discovered that when I retire a document, the 
> document disappears immediately! Is that right?! I would've 
> expected a 
> publisher to need to approve my retiring of a document first.

I'm not familiar with the inner working of Daisy. Your assumption sounds
reasonable. I hope Steven will look into this.

Bye, Helma

DO NOT REPLY [Bug 35311] - [PATCH] Field widget does not fire ValueChangedEvents

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-06-10 18:33 ---
Ok, it totally makes sense.

Patch applied. Thanks!

-- 
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: FlowApi and JavaFlow

[Ralph Goers]

We have used JavaFlow lightly and have not had any problems. We plan to 
use it more heavily. I don't know if that helps.


Lutz Thomas wrote:


Hi !

I followed your discussion about the CForm flowscript API. Does this 
affect JavaFlow ?


And, as I am in the startup of major project, and want to use 
JavaFlow, is this a safe decision for the future ? There is not much 
documentation around there, so I am not sure wether this block is 
stable enough for production use…


Thanks for your answers, regards,

Tom

p.s.: Sorry for the “reposting”, but are there any opinions to my 
http://www.mail-archive.com/dev@cocoon.apache.org/msg31732.html post ?

Re: compiling a custom transformer

[Ralph Goers]

I use maven to do my builds. The jars are all in our local repository. 
These are the dependencies I have in my project.xml to compile:


 cocoon
 cocoon
 http://cocoon.apache.org/2.1/
   
   
 excalibur
 excalibur-sourceresolve
 http://avalon.apache.org/
   
   
 excalibur
 excalibur-pool
 http://avalon.apache.org/
   
   
 avalon-framework
 avalon-framework
 http://avalon.apache.org/
   

And these are the additional dependencies I have for testing:

 excalibur
 excalibur-component
 http://avalon.apache.org/
   
   
 excalibur
 excalibur-i18n
 http://avalon.apache.org/
   
   
 excalibur
 excalibur-logger
 http://avalon.apache.org/
   
   
 excalibur
 excalibur-instrument
 http://avalon.apache.org/
   
   
 excalibur
 excalibur-xmlutil
 http://avalon.apache.org/
   
   
 cocoon
 cocoon-tests
 http://cocoon.apache.org/2.1
   

I guess I need to change the urls for avalon though. :-)

HTH,
Ralph


Lars Huttar wrote:


Hello,

I've been wanting to use the ValidationTransformer and 
ValidationTransformerReporter described on the wiki at

http://wiki.apache.org/cocoon/ValidationTransformer
The source code is given in some java files but I'm having trouble
compiling them.

In particular, the code has imports for various other Cocoon components.
I could add all the .jar files Cocoon uses into the CLASSPATH, but that
would be pretty laborious.
What is the normal mechanism for compiling such Java files? Of course I
will then want to put the classes into a jar, install that in the right
place, and have Cocoon find it.
Can I accomplish all that by putting the files into a new block? If so,
what is the procedure for creating a block?

I have searched around on cocoon.apache.org and the wiki and mailing 
list archives for info on creating a block, but all I see is 
discussion about how blocks should be designed to work in the future.


Any help would be appreciated.

I have contacted the author of ValidationTransformer a couple of times 
but have not received a reply.


Lars

Re: [Docs] Refactoring, porting Wiki content, and evaluating Daisy

[Mark Leicester]

One more thing: I just discovered that when I retire a document, the 
document disappears immediately! Is that right?! I would've expected a 
publisher to need to approve my retiring of a document first.


Mark


On 10 Jun 2005, at 17:40, Linden H van der (MI) wrote:


Really, you want it so that editors and publishers can see it, but
guests can't.


Eh, yes, but since publishers 'automagically' get the editors role as
well, I mentioned the editors only.


Maybe a switch between published and latest would be good.


This exists for a SimpleDocument (but only for the second and following
versions), but AFAICT not for the navigation document. I now try to
publish a new document that Mark has created as soon as possible so he
can switch between live and latest versions.


Would it be possible to achieve this by setting up two
different sites,
one with 'only published docs' and one with 'unpublished docs', and
maybe prevent guests from seeing the latter?


I noticed queries for unpublished docs, but I have no clue if it's
possible to set up a site that prevents guest from accessing it.

Bye, Helma

compiling a custom transformer

[Lars Huttar]

Hello,

I've been wanting to use the ValidationTransformer and 
ValidationTransformerReporter described on the wiki at

http://wiki.apache.org/cocoon/ValidationTransformer
The source code is given in some java files but I'm having trouble
compiling them.

In particular, the code has imports for various other Cocoon components.
I could add all the .jar files Cocoon uses into the CLASSPATH, but that
would be pretty laborious.
What is the normal mechanism for compiling such Java files? Of course I
will then want to put the classes into a jar, install that in the right
place, and have Cocoon find it.
Can I accomplish all that by putting the files into a new block? If so,
what is the procedure for creating a block?

I have searched around on cocoon.apache.org and the wiki and mailing 
list archives for info on creating a block, but all I see is discussion 
about how blocks should be designed to work in the future.


Any help would be appreciated.

I have contacted the author of ValidationTransformer a couple of times 
but have not received a reply.


Lars

Re: FlowApi and JavaFlow

[Gregor J. Rothfuss]

Lutz Thomas wrote:


And, as I am in the startup of major project, and want to use JavaFlow, is
this a safe decision for the future ? There is not much documentation around
there, so I am not sure wether this block is stable enough for production
use...


we use javaflow in production, although not with cforms.

RE: FYI Broken link on download mirrors page

[Linden H van der (MI)]

> On http://cocoon.apache.org/mirror.cgi the link to the explanation as 
> to why there are no binary distributions points to the old 
> wiki.cocoondev.org address (and does not redirect).

Hmm, since this is only a small amount of text I would simply include it
in the page, rather than referring to a link that can become (and now
is) outdated.

Bye, Helma

Re: Build Cocoon 2.1.7

[[EMAIL PROTECTED]]

Hi again, :(

ok, with the solution that i responsed in my previous mail i can build
correctly cocoon but now i have the next fail when i do
http://localhost:8080/cocoon

excepción 
javax.servlet.ServletException: Servlet.init() para servlet Cocoon lanzó excepción
	org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
	org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
	org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
	org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:738)
	org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
	org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
	org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
	java.lang.Thread.run(Thread.java:595)

causa raíz 
java.lang.NullPointerException
	org.apache.cocoon.servlet.multipart.RequestFactory.(RequestFactory.java:61)
	org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:473)
	org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
	org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
	org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
	org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:738)
	org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
	org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
	org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)

I use Tomcat 5.

Any idea?

Best desires

	java.lang.Thread.run(Thread.java:595)





[EMAIL PROTECTED] escribió:
Hello
again,
  
  
I ask and i reply me. XD
  
  
The solution is to create a empty folder in src/blocks/stx/java
  
  
Best regards
  
  
  
  
[EMAIL PROTECTED] escribió:
  
  
  Hello everybody,


I am having problems to build the src version of cocoon-2.1.7.


I am excluding the "stx" block with my local.block.properties.

excluded:

 NOTICE 

...

Block 'stx' is excluded from the build.

...





...but later on:


BUILD FAILED

/mnt/data/home/usuario/Elvira/Binarios/cocoon-2.1.7/tools/targets/docs-build.xml:264:
The following error occurred while executing this line:

/mnt/data/home/usuario/Elvira/Binarios/cocoon-2.1.7/build/cocoon-2.1.7/temp/blocks-build.xml:619:
/mnt/data/home/usuario/Elvira/Binarios/cocoon-2.1.7/src/blocks/stx/java
not found.



Anybody knows what is going on and how to fix that?


salu2



-- Elvira Nieto Carretero

  Isotrol, S.A.


-

 Isotrol, S.A.

 Edificio Innova

 Avda. de la Innovacion, 1, 3ª planta

 41020 SEVILLA

 Tel.: 955 036 800 Fax: 955 036 849

 Correo-e: [EMAIL PROTECTED]



  
  
  
--     Elvira Nieto Carretero
  
  Isotrol, S.A.
  
  
-
  
 Isotrol, S.A.
  
 Edificio Innova
  
 Avda. de la Innovacion, 1, 3ª planta
  
 41020 SEVILLA
  
 Tel.: 955 036 800 Fax: 955 036 849
  
 Correo-e: [EMAIL PROTECTED] 
  
  




--   
   Elvira Nieto Carretero
   Consultora y Analista de Portales de Internet
   Isotrol, S.A.

-
  Isotrol, S.A.
  Edificio Innova
  Avda. de la Innovacion, 1, 3ª planta
  41020 SEVILLA
  Tel.: 955 036 800 Fax: 955 036 849
  Correo-e: [EMAIL PROTECTED] 
 

RE: [Docs] Refactoring, porting Wiki content, and evaluating Daisy

[Linden H van der (MI)]

> Really, you want it so that editors and publishers can see it, but 
> guests can't.

Eh, yes, but since publishers 'automagically' get the editors role as
well, I mentioned the editors only.

> Maybe a switch between published and latest would be good.

This exists for a SimpleDocument (but only for the second and following
versions), but AFAICT not for the navigation document. I now try to
publish a new document that Mark has created as soon as possible so he
can switch between live and latest versions.

> Would it be possible to achieve this by setting up two 
> different sites, 
> one with 'only published docs' and one with 'unpublished docs', and 
> maybe prevent guests from seeing the latter?

I noticed queries for unpublished docs, but I have no clue if it's
possible to set up a site that prevents guest from accessing it.

Bye, Helma

Re: FYI Broken link on download mirrors page

[Upayavira]

Mark Leicester wrote:
On http://cocoon.apache.org/mirror.cgi the link to the explanation as to 
why there are no binary distributions points to the old 
wiki.cocoondev.org address (and does not redirect).

Mark


I've edited mirror.html on Minotaur (also occurred in 
dist/cocoon/README.html), which seems like it should do it. But the page 
hasn't changed. Any ideas? And, is there a source version of this 
somewhere?


And, while we're at it, our nightly snapshots are of CVS :-(

I'll get on to infra about that.

Regards, Upayavira

Re: [Docs] Refactoring, porting Wiki content, and evaluating Daisy

[Upayavira]

Linden H van der (MI) wrote:

Hi Mark,
The navigation (and every document for that matter) can include queries.
So what I want is a navigation section that basically displays all
documents available (including the unpublished ones). The only problem
now is to whom it will be visible.


Really, you want it so that editors and publishers can see it, but 
guests can't.


Maybe a switch between published and latest would be good.

Would it be possible to achieve this by setting up two different sites, 
one with 'only published docs' and one with 'unpublished docs', and 
maybe prevent guests from seeing the latter?


Just a thought.

Upayavira

Re: [osgi] Package structure

[Daniel Fagerstrom]

Bertrand Delacretaz wrote:

Le 7 juin 05, à 23:43, Sylvain Wallez a écrit :


Daniel Fagerstrom wrote:

...So IMO we need a policy for package naming. Is there any "style 
guide" for package names for Eclipse plugins that we can adapt? 
Otherwise using something like:


  org.apache.cocoon.blockname.**


Yep. That's how it's done for Eclipse plugin. Each plugin has a name 
which is unique among all plugin and which is the root package for 
classes contained in the plugin...


Just thinking, because I'm working on a block:

  org.apache.cocoon.blocks.blockname.**

might be better, the blocks prefix makes name clashes less probable.


The package names start to become rather long that way. We control 
org.apache.cocoon so we should be able to control the name space anyway IMO.


/Daniel

P.S.

I will be offline the comming week (sailing). Feel free to finish the 
OSGi stuff while I'm away ;)

Re: [Docs] Refactoring, porting Wiki content, and evaluating Daisy

[Mark Leicester]

Hi Helma,

On 10 Jun 2005, at 09:12, Linden H van der (MI) wrote:


However, I don't think it's a good idea to put this info at the bottom
of the wiki page. I'd rather put it on the top like:

The content of this page is moved to . Updates to the
content will be done there. This page will no longer be reviewed for
updates and will be removed in due time.


Yep, good idea, I'll do that.

Another question: how do include anchors within pages? Should I do it 
manually with the HTML view?


Mark

Re: Build Cocoon 2.1.7

[[EMAIL PROTECTED]]

Hello again,

I ask and i reply me. XD

The solution is to create a empty folder in src/blocks/stx/java

Best regards



[EMAIL PROTECTED] escribió:


Hello everybody,

I am having problems to build the src version of cocoon-2.1.7.

I am excluding the "stx" block with my local.block.properties.
excluded:
 NOTICE 
...
Block 'stx' is excluded from the build.
...



...but later on:

BUILD FAILED
/mnt/data/home/usuario/Elvira/Binarios/cocoon-2.1.7/tools/targets/docs-build.xml:264: 
The following error occurred while executing this line:
/mnt/data/home/usuario/Elvira/Binarios/cocoon-2.1.7/build/cocoon-2.1.7/temp/blocks-build.xml:619: 
/mnt/data/home/usuario/Elvira/Binarios/cocoon-2.1.7/src/blocks/stx/java 
not found.



Anybody knows what is going on and how to fix that?

salu2


-- Elvira Nieto Carretero
  Isotrol, S.A.

-
 Isotrol, S.A.
 Edificio Innova
 Avda. de la Innovacion, 1, 3ª planta
 41020 SEVILLA
 Tel.: 955 036 800 Fax: 955 036 849
 Correo-e: [EMAIL PROTECTED]





--   
  Elvira Nieto Carretero

  Isotrol, S.A.

-
 Isotrol, S.A.
 Edificio Innova
 Avda. de la Innovacion, 1, 3ª planta
 41020 SEVILLA
 Tel.: 955 036 800 Fax: 955 036 849
 Correo-e: [EMAIL PROTECTED] 

Sitemap: flow and interpreters

[Carsten Ziegeler]

While inspecting the current sitemap (tree builder) code for flow,
I'm wondering about the support for different languages.

The basic question first: do we want to support more than one flow
language per sitemap?

If yes, imho this isn't supported yet. It's possible to register
scripts for different interpreters in a single sitemap. But as
each flow node (containing the scripts) registeres itself at
the tree processor and as the treeprocessor uses a simple map
to store them, the last node wins. In addition there isn't a way
to tell the call function node which language it should use.

I think we should either allow only one script language per sitemap
or we should fix the current code. I prefer the second solution.

WDYT?

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

DO NOT REPLY [Bug 35311] - [PATCH] Field widget does not fire ValueChangedEvents

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





--- Additional Comments From [EMAIL PROTECTED]  2005-06-10 17:21 ---
(In reply to comment #3)
> FormHandler was introduced at the early stages of CForms (when it was still
> called Woody), long before we added the current event handling system, and I 
was
> thinking about deprecating it.
> Can you explain your use case, and why FormHandler is more appropriate than a
> ValudChangedListener on the widget?

Capturing all events in a single class and then dispursing them appropriately 
makes it extremely convenient.  For instance, we are tracking all changes to a 
form, and handling these changes with a generic "Tracker" makes for less coding 
rather than attaching a listener to every widget on a form.

-- 
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: CForms Summer of Code project

[Sylvain Wallez]

Reinhard Poetz wrote:


Max Pfingsthorn wrote:


Hi again!

This is mainly to Reinhard and Sylvain, I guess. Who else is a CForms
guru here? :)



IIRC the idea came from Tim Larson who has also started with some 
experimental code 
(http://svn.apache.org/repos/asf/cocoon/whiteboard/forms/) but I have 
to admit that I don't know what the current status of it is.


The design and the implementation will be discussed on this list and 
anybody who's interested can take part in the discussions. I'm willing 
to take the role of the official mentor but I would like a co-mentor 
who knows cForms in depth (Sylvain, Tim, Bruno, ...). This person 
doesn't need to be officially named but he is more a backup for Max if 
the whole community is on holidays and he needs a contact person for 
technical questions. Tim has already offered to help "unofficially", 
right? (Just asking again for Max.)


I also want a second person as official mentor as I will be offline 
for some weeks over the summer. Anybdoy volunteering?



Me, me :-)


I have a question about the inheritance and namespace/inclusion
semantics which are not really discussed in the wiki.

1. What about nested libraries? In the wiki it says it forms a flat
namespace. Would that be like this: include library 1 as "lib1" and
library 2 (from library 1) as "lib2", then all macros of lib2 will
still be accessible as lib2:name in a definition which includes lib1?
It also mentions a tree like model (I guess like java packages?),
which would result in "lib1:lib2:name" to resolve to a macro in lib2?
I guess both would be sort of easy to implement.



leave it open for now. We will have to talk more about usecases and 
decide then.



2. Can any widget type be macro-ized or only fields? I guess any would
make sense... 



any type


Can macros be extended in the form definition?



hmmm, good questions. I'd say yes, but I can't think of a simple 
syntax now. Ideas?



3. Extension/Inheritance of widgets may be a problem as currently the
validation of configs is done within the builders'
buildWidgetDefinition() method. May need to implement
"extendWidgetDefinition(Element, WidgetDefinition)" for each of the
builders. Default may be to just return the given definition. Could be
called in 
AbstractWidgetDefinitionBuilder.buildAnotherWidgetDefinition().

Do you think that would that solve it?



I hope somebody who with in-depth knowledge can answer this.



Me too :-)


4. What exactly is the NewDefinition for? For dynamic form generation?
In that case, I guess, I can reuse some of it's parts for the
MacroDefinition(Builder), yes?



same here as before



5. What about caching or reloading libraries if they changed? How is
that handled right now?



AFAIU, when the form is created by the FormManager it gets all its 
widgets set. If a library of the form is changed after that, this 
doesn't have an impact on "living" form instances.




Sorry if I am rambling a bit... Once I get this straightened out, I
will post my ideas for a solution on the wiki, like requested.



Fine!




--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: ImageMap: the donation

[Luca Morandini]

Peter Hunsberger wrote:


On 6/10/05, Luca Morandini <[EMAIL PROTECTED]> wrote:

Note there is no need for the verbose XSLT element, attribute syntax
here, you can just use something like:


Sure, that was a leftover from various experiments I did and then forgot 
to streamline.


Regards,

   Luca Morandini
www.lucamorandini.it

FlowApi and JavaFlow

[Lutz Thomas]

Hi !

 

I followed your discussion about the CForm flowscript
API. Does this affect JavaFlow ?

 

And, as I am in the startup of major project, and
want to use JavaFlow, is this a safe decision for the future ? There is not
much documentation around there, so I am not sure wether this block is stable
enough for production use…

 

Thanks for your answers, regards,

Tom

 

p.s.: Sorry for the “reposting”, but are
there any opinions to my http://www.mail-archive.com/dev@cocoon.apache.org/msg31732.html
post ?

 

Re: CForms stabilization tasks (was Re: Marking cforms stable in 2.1.8)

[Sylvain Wallez]

Reinhard Poetz wrote:


Sylvain Wallez wrote:

I personally don't use v2 nor v3. People using it are invited to 
speak up!



You answered the question in your summary of the last year GT 
Hackathon discussion about cforms 
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109774752401800&w=2) 
yourself:


[...]
- don't use JS wrapping classes for widgets: they introduce 
yet-another-API which is sometimes confusing.
- update the widgets' java public API so that it's more 
"Rhino-friendly" (check JavaBean conformance and add accessors where 
needed)



So this speaks for a removal of form.model...


- implement an equivalent to the bookmark feature of V2, by a function
property of the form that gets called at each request roundtrip



Done: see cleanupHook and restoreHook in Form.js


- add helper methods to the Form class to create event listeners from JS
functions



Can be done quickly, and doesn't prevent marking state stable as it will 
be an addition


- restrict the "cocoon" object that's available in the event handlers 
so that it does not provide response-related methods (sendPage etc)



To be done.

Sylvain

--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: CForms stabilization tasks (was Re: Marking cforms stable in 2.1.8)

[Sylvain Wallez]

Paul Crabtree wrote:


Hi, i've just finished quite a large cocoon site using 2.1.7 with
Forms V3. We choose this version for two reasons:

1. At the time i couldnt find much info on the different versions or
why they were there so assumed V3 meant it was more mature and the
latest.
 



Well, yes, the latest, but the youngest and therefore not the more 
mature :-)



2. showForm() in V3 offers the ability to send viewData


V1 does also


and declare a function for execution after the form has been shown each time.



V1 does also, allowing two functions to handle the iterative nature of 
showForm: one after the page has been displayed (for cleanup) and one 
when the browser submits the form (for restoring).



V2
allows a function but no viewData and V1 allows viewData but no
function (i think). We therefore felt V3 had a richer, more flexible
JS API and we thought we were going to need the function and viewData
for our project.
 



Ok. So the good news is that V1 does all what you need and more !

Sylvain

--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

DO NOT REPLY [Bug 35311] - [PATCH] Field widget does not fire ValueChangedEvents

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





--- Additional Comments From [EMAIL PROTECTED]  2005-06-10 17:14 ---
FormHandler was introduced at the early stages of CForms (when it was still
called Woody), long before we added the current event handling system, and I was
thinking about deprecating it.

Can you explain your use case, and why FormHandler is more appropriate than a
ValudChangedListener on the widget?

-- 
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: [osgi] Package structure

[Bertrand Delacretaz]

Le 7 juin 05, à 23:43, Sylvain Wallez a écrit :


Daniel Fagerstrom wrote:
...So IMO we need a policy for package naming. Is there any "style 
guide" for package names for Eclipse plugins that we can adapt? 
Otherwise using something like:


  org.apache.cocoon.blockname.**



Yep. That's how it's done for Eclipse plugin. Each plugin has a name 
which is unique among all plugin and which is the root package for 
classes contained in the plugin...


Just thinking, because I'm working on a block:

  org.apache.cocoon.blocks.blockname.**

might be better, the blocks prefix makes name clashes less probable.

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature

Re: ImageMap: the donation

[Peter Hunsberger]

On 6/10/05, Luca Morandini <[EMAIL PROTECTED]> wrote:



> -
> CHANGES TO FORM-FIELD-STYLING.XSL
> -
> 

Note there is no need for the verbose XSLT element, attribute syntax
here, you can just use something like:

   

 
 
 




-- 
Peter Hunsberger

ImageMap: the donation

[Luca Morandini]

Folks,

The ImageMap widget is done. Doc about the widget is included in this 
message, as it is the field styling changes, while the Java source can 
be downloaded at http://www.lucamorandini.it/imagemap.zip


...enjoy :)

--
IMAGEMAP CONFIGURATION
--

This element has to be added to the forms-form.xconf:




-
IMAGEMAP WIDGET REFERENCE
-

ImageMap widget

It is used to display a server-side image map and it triggers an 
ImageMap event on the server side when clicked.
It behaves much as an Action widget, but you can bind the source URI of 
the image using the binding framework "fb:value" element, set the image 
at runtime using the setImageURI() method, and retrieve the mouse 
coordinates with getX() and getY() methods.


A simple example follows:

Form definition document:

test.gif
Click on this map to zoom-in

onClickMap(event);



Form binding document (you can set the image URI with binding as well):


Form template:

http://apache.org/cocoon/forms/1.0#instance";
border="2"/>


Flow:
This is another way to set the image URI: 
frm.getWidget().lookupWidget("map").setImageURI("test2.gif");


This is the handler of the imagemap event:
function onClickMap (event) {
var x= event.getX();
var y= event.getY();
var uri;

uri= map.zoomIn(new Rectangle(new Point(x, y), 1, 1));
if ( uri != "map.zoominTooFar" ) {
event.getSource().setImageURI(uri);
}
}

-
CHANGES TO FORM-FIELD-STYLING.XSL
-

  
  

image

			select="@imageuri"/>
			select="fi:hint"/>

true




  

-
JAVA SOURCE FILES
-

Event package:
ImageMapEvent.java

FormModel package:
ImageMap.java
ImageMapDefinition.java
ImageMapDefinitionBuilder.java


   Luca Morandini
www.lucamorandini.it

DO NOT REPLY [Bug 35311] - [PATCH] Field widget does not fire ValueChangedEvents

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





--- Additional Comments From [EMAIL PROTECTED]  2005-06-10 15:49 ---
Created an attachment (id=15367)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15367&action=view)
Field.java patch


-- 
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.

cocoon forms sample

[nira bal]

Currently we are interested in developing advanced forms using cocoon piplines.I have browse through the information required to build the forms under CForms Block Samples-basic examples/various (actions). The sitemap.xmap file contains all forms and flow script. I just confused to build one. Could send the source code to build , for the just various action forms.
 
 
Nira
Contact on
    [EMAIL PROTECTED]
 
 
 
 
sample required:
Content ViewSourceSitemap 
Sample form



String fieldsNumber fieldsBoolean fields 




Enter an email address:

* 




Select something that's 4 characters long:

 aaa


Please enter a number(will automatically set a correct value below if needed):

* 


Enter another number, larger than the other number:

* 


Indicate the size of your bank account (in m3):

 12three45


Indicate your height (in cows):







1

 




2




three




4




5






 




 Put me on or off. 


Indicate which 2 of the following drinks you'd like to receive:






Available drinks

 

Your selection


 Coca ColaHoegaardenJupilerLeffeMaes

  ">    >">          







Checkout the form1 flow page for another way of formatting panels

Misc controls   





Enter your (16-digit) visa number (without spaces) Your credit card will be billed. Valid test number is: 4111 

* 




Please enter your IP address

* 


Select a date on which you'd rather had been born:

 Wednesday, 11 July 1302Sunday, 23 June 1912Monday, 21 July 1969Wednesday, 6 May 1970Saturday, 14 October 1978Tuesday, 11 September 2001* 


Select another date on which you'd rather had been born:

 Wednesday, 1 January 2003Thursday, 1 January 2004Monday, 6 June 2005* 


Your birthdate (dd/MM/):

 * 


Price for a liter diesel:

* 
 





Firstname

Lastname

Phone

Email

Birthdate (dd/MM/):

Select










 












 






 

 

An email address must be in [EMAIL PROTECTED] format. And if you do not know what email address is, then well, chances are that you do not have it. However, if you have access to the Internet, you can easily get yourself one! Choose one of the
 following options: 

Yahoo! Mail 
Hotmail 
Anyway, the point of all this was to show a popup help with mixed html content. 
Use a fake number if Cocoon is not running on your local computer
 
		Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone.

Re: svn commit: r189955 - in /cocoon: blocks/scratchpad/trunk/java/org/apache/cocoon/acting/ blocks/scratchpad/trunk/samples/ blocks/scratchpad/trunk/samples/flow-action/ trunk/src/java/org/apache/cocoon/components/treeprocessor/sitemap/

[Reinhard Poetz]

Carsten Ziegeler wrote:

Leszek Gawron wrote:

Why do we add it at all? Some time ago we did not require flowscript to 
sendPage so people used it for actions. Now we introduce a hackish 
FlowAction to do what we've banned ourselves.


Or am I wrong?



Don't know. Currently a sendPage is required in flow if you use the
map:call function, so you can't use it.
Actually I want to use flow script for prototyping different things,
and not just only flow with continuations. The action is only a
prototype to see what is possible and what is not. As long as we
provide a clean way to get the interpreter we can remove the action.
But the action is a proof that accessing the interpreter is
currently not possible. So we should imho fix that.


yes we need this, especially to make inter block communiction possible:

var x = cocoon.blocks.blockA.myFunc();


Using a script language enables faster prototyping!


Have you converted to a Javascript fan ;-)
(With the reloading classloader and Eclipse I'm more than satisfied with a usual 
action and Java ;-)


--
Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach 


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

   web(log): http://www.poetz.cc

RE: [Docs] Refactoring, porting Wiki content, and evaluating Daisy

[Linden H van der (MI)]

Hi Mark,

Thanks for putting in all the work. I have reviewed the documents,
straightened out some layout glitches and put them live. So you should
now be able to see your work.

> I created a CategoryInDaisy page in the Wiki, so that it is easy to 
> record a wiki page as having been transferred. Perhaps we could have 
> CategoryDaisyInProgress, CategoryDaisyComplete? I also 
> recorded on the 
> Wiki page where a piece of content has gone (i.e. a Wiki page may be 
> split or combined).

Keep it like this for now and when further categories are necessary.
However, I don't think it's a good idea to put this info at the bottom
of the wiki page. I'd rather put it on the top like:

The content of this page is moved to . Updates to the
content will be done there. This page will no longer be reviewed for
updates and will be removed in due time.

People can then judge for themselves if they want to go to the new site
or not.

> On the other hand, the negatives are:
>  * Newly created pages are invisible until they are published (by 
> someone with publishing rights). It's a little like flying 

True. I've discussed it with Steven already. What I'd like to see is a
switch between the current version and the latest but unpublished
version, without changing into the editor.

> to remember document IDs in order to cross-link (unpublished pages 
> don't show up in the link chooser). I couldn't review my 

Have you tried the query search at the top? It also gives some "common"
queries and one of them is 'all docs with unpublished latest version'.
It then produces a list that includes the id.

>  * Switching between the navigation structure editor and the page 
> editor was tedious. I understand the power of this 
> separation, but from 
> a usability point of view it would be nice to make the 
> management of a 
> page's location possible from the page itself.

The navigation (and every document for that matter) can include queries.
So what I want is a navigation section that basically displays all
documents available (including the unpublished ones). The only problem
now is to whom it will be visible.

HTH.

And keep up the good work!

Bye, Helma

Re: svn commit: r189955 - in /cocoon: blocks/scratchpad/trunk/java/org/apache/cocoon/acting/ blocks/scratchpad/trunk/samples/ blocks/scratchpad/trunk/samples/flow-action/ trunk/src/java/org/apache/cocoon/components/treeprocessor/sitemap/

[Carsten Ziegeler]

Leszek Gawron wrote:
> 
> Why do we add it at all? Some time ago we did not require flowscript to 
> sendPage so people used it for actions. Now we introduce a hackish 
> FlowAction to do what we've banned ourselves.
> 
> Or am I wrong?
> 
Don't know. Currently a sendPage is required in flow if you use the
map:call function, so you can't use it.
Actually I want to use flow script for prototyping different things,
and not just only flow with continuations. The action is only a
prototype to see what is possible and what is not. As long as we
provide a clean way to get the interpreter we can remove the action.
But the action is a proof that accessing the interpreter is
currently not possible. So we should imho fix that.
Using a script language enables faster prototyping!

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

DO NOT REPLY [Bug 35311] - [PATCH] Field widget does not fire ValueChangedEvents

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





--- Additional Comments From [EMAIL PROTECTED]  2005-06-10 15:49 ---
Created an attachment (id=15366)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15366&action=view)
Form.java patch


-- 
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.

DO NOT REPLY [Bug 35311] New: - [PATCH] Field widget does not fire ValueChangedEvents

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

   Summary: [PATCH] Field widget does not fire ValueChangedEvents
   Product: Cocoon 2
   Version: 2.1.7
  Platform: All
OS/Version: All
Status: NEW
  Severity: major
  Priority: P2
 Component: CocoonForms
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


The field widget does not fire ValueChangedEvents when only a FormHandler is 
attached to a Form.  A FormHandler is supposed to receive all events from all 
widgets on a Form.  The proposed patch adds an additional validation check to 
the Field.hasValueChangedListeners() method.

-- 
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: svn commit: r189955 - in /cocoon: blocks/scratchpad/trunk/java/org/apache/cocoon/acting/ blocks/scratchpad/trunk/samples/ blocks/scratchpad/trunk/samples/flow-action/ trunk/src/java/org/apache/cocoon/components/treeprocessor/sitemap/

[Leszek Gawron]

[EMAIL PROTECTED] wrote:

Author: cziegeler
Date: Fri Jun 10 06:27:54 2005
New Revision: 189955

URL: http://svn.apache.org/viewcvs?rev=189955&view=rev
Log:
Add FlowAction that executes a function defined in flow script.
Add hack to get the current flow Interpreter - we need a better way
Why do we add it at all? Some time ago we did not require flowscript to 
sendPage so people used it for actions. Now we introduce a hackish 
FlowAction to do what we've banned ourselves.


Or am I wrong?

--
Leszek Gawron  [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: CForms stabilization tasks (was Re: Marking cforms stable in 2.1.8)

[Paul Crabtree]

Hi, i've just finished quite a large cocoon site using 2.1.7 with
Forms V3. We choose this version for two reasons:

1. At the time i couldnt find much info on the different versions or
why they were there so assumed V3 meant it was more mature and the
latest.

2. showForm() in V3 offers the ability to send viewData and declare a
function for execution after the form has been shown each time. V2
allows a function but no viewData and V1 allows viewData but no
function (i think). We therefore felt V3 had a richer, more flexible
JS API and we thought we were going to need the function and viewData
for our project.

Hope this helps.

Paul



On 6/10/05, Reinhard Poetz <[EMAIL PROTECTED]> wrote:
> Sylvain Wallez wrote:
> 
> > I personally don't use v2 nor v3. People using it are invited to speak up!
> 
> You answered the question in your summary of the last year GT Hackathon
> discussion about cforms
> (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109774752401800&w=2) 
> yourself:
> 
> [...]
> - don't use JS wrapping classes for widgets: they introduce
> yet-another-API which is sometimes confusing.
> - update the widgets' java public API so that it's more "Rhino-friendly"
> (check JavaBean conformance and add accessors where needed)
> - implement an equivalent to the bookmark feature of V2, by a function
> property of the form that gets called at each request roundtrip
> - add helper methods to the Form class to create event listeners from JS
> functions
> - restrict the "cocoon" object that's available in the event handlers so
> that it does not provide response-related methods (sendPage etc)
> [...]
> 
> --
> Reinhard Pötz   Independent Consultant, Trainer & (IT)-Coach
> 
> {Software Engineering, Open Source, Web Applications, Apache Cocoon}
> 
> web(log): http://www.poetz.cc
> 
>