Re: handling errors in parts

2006-03-09 Thread Derek Hohls
Bruno
 
Are there any samples available to show the effective use of the 
processPipelineTo in the manner you describe?
 
Sidebar:
 
It would be great to have set of samples which demonstrate
how and why to use many of the functions which are (in my
limited understanding, anyway!) quite cryptically described in:
http://cocoon.apache.org/2.1/userdocs/flow/api.html 
(especially as flowscript seems more and more to be a replacement
for older ways of doing things - "the more you less know, the more
you are hindered by your own knowledge"!)


>>> [EMAIL PROTECTED] 2006/03/09 08:52 PM >>>

On Thu, 2006-03-09 at 12:52 -0500, Justin Hannus wrote:
> I can't seem to get an aggregate pipeline part to respect or handle 
> errors correctly when an
> exception occurs in one of the aggregate parts. It almost seems as if 
> its impossible. This is
> whats happening...
> 
> When an exception occurs in the a pipeline which is called as one of the 
>  part elements, the erroring pipeline or parent pipelines 
> do not handle the errors correctly. In fact, the  is 
> completely ignored. What happens is the sitemap processing continues 
> even after the exception occurs and, eventually the main entry matching 
> pipeline's  is invoked. This is bad because when using a 
> cocoon:// request as your  src any pipelines under that 

what do you refer to with 'pipelines' here? The other map:part's?
Transformers after the map:aggregate?

> cocoon:// request will continue processing as if no error has occurred 
> but. you will still see the cocoon error page as if processing 
> actually stopped!
> 
> I have a pipeline which aggregates several other pipelines and then 
> writes the generated content to disk. If there is an exception in one of 
> the aggregate parts I need the sitemap processing to stop and handle the 
> exception appropriately. Instead the generated content, which has 
> errored and therefore invalid, is still written to disk. If I remove the 
> aggregate pipeline and just use a regular generator the handle-errors is 
> respected correctly and processing stops before writing the content.
> 
> Am I misusing the  elements? Or is this the expected 
> behavoir?
> 

I have no experience with map:aggregate, but from a quick look at the
code, it doesn't catch any exceptions. What it does always do (also when
an exception occurs) is closing the root tag and sending the end
document event.

Now I'm just going to guess wildly (since you didn't mention), but if
after the map:generate you have an XSLT transformer and you write the
content using the source writing transformer, I can image the file
indeed still gets written. This is because on the one hand Xalan can
cope with the invalid input, and the endDocument event will cause it to
do the transform and thus cause the source writing transformer to do its
job.

While the close-root-tag-and-send-end-document-event behaviour of the
aggregate is debatable, it is the nature of a SAX-pipeline that
everything in the pipeline starts executing together. Therefore things
which have side-effects and for which error recovery is important should
not be done in a streaming pipeline (therefore the source writing
transformer is considered an evil one -- don't use it).

The alternative approach is to use flowscript and its processPipelineTo
function, where you can use a try-catch block and remove the file (if
needed) when an error occurs.

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED] 
For additional commands, e-mail: [EMAIL PROTECTED] 




-- 
This message is subject to the CSIR's copyright, terms and conditions and
e-mail legal notice. Views expressed herein do not necessarily represent the
views of the CSIR.
 
CSIR E-mail Legal Notice
http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html 
 
CSIR Copyright, Terms and Conditions
http://mail.csir.co.za/CSIR_Copyright.html 
 
For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR
Legal Notice send a blank message with REQUEST LEGAL in the subject line to
[EMAIL PROTECTED]


This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: jx templates and syntax

2006-03-09 Thread Kamal Bhatt


Simone Gianni wrote:


Hi Kamal,
dunno why, nut i always have problems like this in jx. Seems like a 
variable declared with :


Content

Takes as value a document fragment, and thus should be converted to 
string or something else to be used "normally".



Really? I found the opposite to be true, at least when I printed the value.


I usually declare the variable with :



And this (again, usually) works in the expected way.

Hope this helps,
Simone

Kamal Bhatt wrote:



Hi.
I was wondering, if this is a bug and if it is,  has been fixed in 
2.1.8 (I am currently on 2.1.7 and do not have access to 2.1.8):


If I create a variable with value of a field eg.

value="${form.getChild('active_repeater').getValue()}"/>


then I reference it in an if eg.


...

I do not enter the code inside of the if but if I change it to this:



it works fine.

Also, while we are on the topic of jx templates, why are they so 
inconsisten with the way we do things in XSLT and XML based "languages".


Cheers.




--
Kamal Bhatt

Tourism Technology Pty Ltd


T:  +61 (02) 9956 7300
F:  +61 (02) 9956 7411


Level 10, 1 Pacific Highway, North Sydney, NSW 2060


http://www.tt.com.au


--
Disclaimer: This email is confidential and may contain privileged information 
for the sole use of the person or business to which it is addressed. If you are 
not the intended recipient, please notify the sender by return e-mail or phone 
as you must not view, disseminate, distribute or copy this email without our 
consent. We do not accept any liability in connection with any computer virus, 
data corruption, incompleteness, or unauthorised amendment of this email. It is 
the sole responsibility of the receiver to scan for viruses before opening.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: jx templates and syntax

2006-03-09 Thread Simone Gianni

Hi Kamal,
dunno why, nut i always have problems like this in jx. Seems like a 
variable declared with :


Content

Takes as value a document fragment, and thus should be converted to 
string or something else to be used "normally".


I usually declare the variable with :



And this (again, usually) works in the expected way.

Hope this helps,
Simone

Kamal Bhatt wrote:



Hi.
I was wondering, if this is a bug and if it is,  has been fixed in 
2.1.8 (I am currently on 2.1.7 and do not have access to 2.1.8):


If I create a variable with value of a field eg.

value="${form.getChild('active_repeater').getValue()}"/>


then I reference it in an if eg.


...

I do not enter the code inside of the if but if I change it to this:



it works fine.

Also, while we are on the topic of jx templates, why are they so 
inconsisten with the way we do things in XSLT and XML based "languages".


Cheers.


--
Simone Gianni

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Flow and hibernate sessions

2006-03-09 Thread Simone Gianni




Hi Mark,
don't want to start a thread on which solution is better than another,
they all try to get there :) . I find your solution much more
complicated, the hibernate adapter is installed with 2 lines in
cocoon.xconf, a "hibernate" word added in the sitemap where you declare
flows, and explicit flush in the DAOs (which someone says is a good
practice anyway). 

Detaching and retaching objects was the solution of
HibernateflowAdapter1 (the one i made before that i sent you), but
brought us only problems : a lot of work in DAOs to merge eventually
preloaded and then modified objects, hibernate not retaching objects or
lazy not working after retach (expecially on collections), duplicated
objects, basically impossible to avoid the situation where an exception
occurrs because of the state of an object that is retached every time,
hibernate persisting partially modified objects between two different
flow steps.

Some of this problems were caused by the hibernate-spring interaction,
so maybe in a pure hibernate configuration this would not happen.

Simone



Mark H wrote:

  
  

  
  
  Hi Simone,
   
  It looks interesting and
complicated! For the moment I’ve
decided to detach the object from the session by calling
Hibernate.initialize()
on the collections and getters on the associations. This is implemented
in the
object’s DAO. This can be used for objects that span a web session as
well as a flow. It would be handy if Hibernate provided a
Hibernate.detach()
method. I know this will introduce unnecessary database fetching for
associations/collections that are not needed, though it’s probably
better
than non-lazy loading. 
   
  I hope to spend sometime
trying to implement your “flow”
wrapper – it looks interesting. Though I’m a little uncomfortable
having open sessions hanging around, though as you said it doesn’t hold
onto database connections.
   
  
  Mark H
  
  
  
  
  From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
  On Behalf Of Simone
Gianni
  Sent: 06 March 2006
18:31
  To:
users@cocoon.apache.org
  Subject: Re: Flow and
hibernate
sessions
  
   
  Hi Mark,
we had the same problem with Hibernate. I solved it with a "flow"
wrapper. This wrapper wraps the flow interpreter of your choice (tested
with
javaflow a lot, simple tests with _javascript_, but should not give big
problems), opens a new session when the flow is first accessed
(map:call
function), detaches the session from the DB when the flow sends a page,
then
retaches the same session when the continuation is invoked (map:call
continuation). It schedules a task to recollect and close sessions
connected to
continuations which has been marked as invalid.
  
This magically gives you a coherent hibernate session inside your flow,
but it
has some drawbacks :
- Sessions are left there, open (but disconnected from the database, so
the DB
collection is free) for all the time it takes for the continuation tree
to be
marked invalid, so potentially much more than needed, but there isn't
currently
a notion of "flow finished", so i don't think there can be any other
way. This will increase memory usage.
- It's written for a hibernate + spring configuration, since it uses
spring
transaction manager to set the session as "current session" while
executing the flow.
- Since the DB connection is detached, it forces a "flush never" to
avoid spring/hibernate to flush the connection and thus persist object
while
they are, for example, being edited in a form or manipulated by the
flow. This
means you must manually flush the connection (or the spring hibernate
template
in DAOs, or whatever else) to persist your changes where needed (you
can access
the session inside the flow with
request.getAttribute("HIBERNATE_SESSION") to do whatever you want
with it). This is again needed since there is no way of knowing
automatically
when it is ok to flush the session and when we are just in an
intermediate
sendpageandwait.
- Since the DB connection is detached, this can create potential
problems in
database transaction for databases which does not support transactions
spanning
different connections (which one does?) when not using another external
transaction system.
  
But also brings many advantages :
- You can use lazy loading everywhere, since the session will be there
as long
as the continuation will be there.
- No more worries about objects being persisted in the middle of a
flow-form interaction
(thus causing hibernate exceptions, or even worse data corruption)
- Hibernate persistence will now be "horizontal and transparent", at
least in your flow (DAO, or backend services, will always need to know
something about hibernate)
- No problems of merging, stale objects, duplicate objects ... that
would arise
with other tecniques (object detach, retach; multiple sessions etc..)
  
We are currently developing a lot of stuff using cocoon + hibernate +
spring
with this component.
  
You can find javadoc in the main HibernateFlowAdapter2 class,
explaining how to
use it, fe

Re: IE filepath error in flowscript - tried getName [solved]

2006-03-09 Thread Daniel Hertz

Thanks Tony for the great tip!

I managed to get it working by using:

var fileName = 
form.lookupWidget("upload").getValue().getHeaders().get("filename").toLowerCase();

 // using getName because Internet Explorer sends entire path
 fileName = new java.io.File(fileName).getName();

Daniel.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: handling errors in parts

2006-03-09 Thread Justin Hannus


Bruno Dumon wrote:


what do you refer to with 'pipelines' here? The other map:part's?
Transformers after the map:aggregate?

 

Yes, the other map:parts. The src attribute points to points to another 
pipeline with cocoon://. Please see my first post as it has an 
example at the bottom. I re-posted the same thread omitting the example 
for brevity.


cocoon:// request will continue processing as if no error has occurred 
but. you will still see the cocoon error page as if processing 
actually stopped!


I have a pipeline which aggregates several other pipelines and then 
writes the generated content to disk. If there is an exception in one of 
the aggregate parts I need the sitemap processing to stop and handle the 
exception appropriately. Instead the generated content, which has 
errored and therefore invalid, is still written to disk. If I remove the 
aggregate pipeline and just use a regular generator the handle-errors is 
respected correctly and processing stops before writing the content.


Am I misusing the  elements? Or is this the expected 
behavoir?


   



I have no experience with map:aggregate, but from a quick look at the
code, it doesn't catch any exceptions. What it does always do (also when
an exception occurs) is closing the root tag and sending the end
document event.

 

That would explain why exceptions are caught and handled after the 
aggregate parts are executed, as if things went fine, and concatenated 
instead of being caught and handled by the map:handle-errors defined in 
the erroring piepline.


BTW: can you point out the file and line you found this on. I've been 
digging but with no luck yet.



Now I'm just going to guess wildly (since you didn't mention), but if
after the map:generate you have an XSLT transformer and you write the
content using the source writing transformer, I can image the file
indeed still gets written. This is because on the one hand Xalan can
cope with the invalid input, and the endDocument event will cause it to
do the transform and thus cause the source writing transformer to do its
job.
 

Exactly correct. Please see my first post as it has an example at the 
bottom. I re-posted the same thread omitting the example for brevity.



While the close-root-tag-and-send-end-document-event behaviour of the
aggregate is debatable, it is the nature of a SAX-pipeline that
everything in the pipeline starts executing together. Therefore things
which have side-effects and for which error recovery is important should
not be done in a streaming pipeline (therefore the source writing
transformer is considered an evil one -- don't use it).

 

I've also tried some other experiments with aggregate map:parts calling 
pipelines and setting request attributes. It seems as if a new Request 
object is created for each map:aggregate part. Therefore setting a 
request attribute in a pipeline when called from a map:part is not 
visible to other map:parts or the original pipeline that contains the 
map:aggregate. In my mind there should always be only one Request 
object. I haven been able to verify this in the source code yet but 
seems to be that case. Another undesirable side-effect of the map:aggregate.



The alternative approach is to use flowscript and its processPipelineTo
function, where you can use a try-catch block and remove the file (if
needed) when an error occurs.
 


I've been trying my hardest to stay away from flowscript :-(

-Justin



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Exception in tomcat catalina.out

2006-03-09 Thread Anna Bikkina

Hi,

I am running my application in cocoon and am using cocoon portals . I 
see the following error in tomcat catalina.out constantly. The 
application seems to work fine. Can anyone explain why I am getting this 
error.


Thanks,
Anna.


java.lang.NullPointerException
   at 
org.apache.cocoon.environment.http.HttpRequest.getRequestURI(HttpRequest.java:227)
   at 
org.apache.cocoon.util.log.CocoonLogFormatter.getURI(CocoonLogFormatter.java:232)
   at 
org.apache.cocoon.util.log.CocoonLogFormatter.formatPatternRun(CocoonLogFormatter.java:175)
   at 
org.apache.cocoon.util.log.ExtensiblePatternFormatter.format(ExtensiblePatternFormatter.java:376)
   at 
org.apache.log.output.AbstractOutputTarget.format(AbstractOutputTarget.java:189)
   at 
org.apache.log.output.AbstractOutputTarget.doProcessEvent(AbstractOutputTarget.java:148)
   at 
org.apache.log.output.AbstractTarget.processEvent(AbstractTarget.java:145)

   at org.apache.log.Logger.fireEvent(Logger.java:708)
   at org.apache.log.Logger.output(Logger.java:683)
   at org.apache.log.Logger.output(Logger.java:666)
   at org.apache.log.Logger.info(Logger.java:206)
   at 
org.apache.avalon.framework.logger.LogKitLogger.info(LogKitLogger.java:117)
   at 
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1167)

   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
   at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
   at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
   at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
   at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
   at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
   at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
   at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
   at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
   at 
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
   at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
   at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
   at 
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
   at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
   at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
   at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
   at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
   at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
   at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
   at 
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
   at 
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
   at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)
   at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
   at 
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
   at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)

   at java.lang.Thread.run(Thread.java:534)
Logging Error: Unknown error writing event.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: handling errors in parts

2006-03-09 Thread Bruno Dumon
On Thu, 2006-03-09 at 12:52 -0500, Justin Hannus wrote:
> I can't seem to get an aggregate pipeline part to respect or handle 
> errors correctly when an
> exception occurs in one of the aggregate parts. It almost seems as if 
> its impossible. This is
> whats happening...
> 
> When an exception occurs in the a pipeline which is called as one of the 
>  part elements, the erroring pipeline or parent pipelines 
> do not handle the errors correctly. In fact, the  is 
> completely ignored. What happens is the sitemap processing continues 
> even after the exception occurs and, eventually the main entry matching 
> pipeline's  is invoked. This is bad because when using a 
> cocoon:// request as your  src any pipelines under that 

what do you refer to with 'pipelines' here? The other map:part's?
Transformers after the map:aggregate?

> cocoon:// request will continue processing as if no error has occurred 
> but. you will still see the cocoon error page as if processing 
> actually stopped!
> 
> I have a pipeline which aggregates several other pipelines and then 
> writes the generated content to disk. If there is an exception in one of 
> the aggregate parts I need the sitemap processing to stop and handle the 
> exception appropriately. Instead the generated content, which has 
> errored and therefore invalid, is still written to disk. If I remove the 
> aggregate pipeline and just use a regular generator the handle-errors is 
> respected correctly and processing stops before writing the content.
> 
> Am I misusing the  elements? Or is this the expected 
> behavoir?
> 

I have no experience with map:aggregate, but from a quick look at the
code, it doesn't catch any exceptions. What it does always do (also when
an exception occurs) is closing the root tag and sending the end
document event.

Now I'm just going to guess wildly (since you didn't mention), but if
after the map:generate you have an XSLT transformer and you write the
content using the source writing transformer, I can image the file
indeed still gets written. This is because on the one hand Xalan can
cope with the invalid input, and the endDocument event will cause it to
do the transform and thus cause the source writing transformer to do its
job.

While the close-root-tag-and-send-end-document-event behaviour of the
aggregate is debatable, it is the nature of a SAX-pipeline that
everything in the pipeline starts executing together. Therefore things
which have side-effects and for which error recovery is important should
not be done in a streaming pipeline (therefore the source writing
transformer is considered an evil one -- don't use it).

The alternative approach is to use flowscript and its processPipelineTo
function, where you can use a try-catch block and remove the file (if
needed) when an error occurs.

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Tab Order in CForms

2006-03-09 Thread Bruno Dumon
On Thu, 2006-03-09 at 17:05 +, Stewart, Gary wrote:
> > I havn't ever tried it, but you can add the tabindex 
> > attribute just like
> > any other, for example:
> > 
> > 
> >   
> > 
> > 
> > The stylesheets simply copy over all the attributes they don't
> > understand to the target input element.
> > 
> > There's also a shorter way of writing this, if you don't have 
> > any nested
> > elements in fi:styling (which is usually the case):
> > 
> > 
> 
> That looks like a good way to go about it; thanks. Gave it a go and it looks 
> like it is working fine on the forms (though it might be a little tedious to 
> change when I make changes to forms I might create a stylesheet to automate 
> adding the attributes to widgets; I can post it when I've done it and if 
> anyone else is interested. 
> 
> However I'd still like to know how I can get access to the cocoon
> resource link since I was also looking at changing the HTMLArea (and
> possibly replacing it with Xinha). 
> 

The resources can be found in:

src/blocks/forms/java/org/apache/cocoon/forms/resources/

What you can do is copy that directory to your own project, and change
the forms resource matcher in your sitemap to read the resources from
the new location. Then you can easily adjust them and try out the
changes (for client-side resources such as javascript, don't forget that
the browser caches these).

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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



handling errors in parts

2006-03-09 Thread Justin Hannus
I can't seem to get an aggregate pipeline part to respect or handle 
errors correctly when an
exception occurs in one of the aggregate parts. It almost seems as if 
its impossible. This is

whats happening...

When an exception occurs in the a pipeline which is called as one of the 
 part elements, the erroring pipeline or parent pipelines 
do not handle the errors correctly. In fact, the  is 
completely ignored. What happens is the sitemap processing continues 
even after the exception occurs and, eventually the main entry matching 
pipeline's  is invoked. This is bad because when using a 
cocoon:// request as your  src any pipelines under that 
cocoon:// request will continue processing as if no error has occurred 
but. you will still see the cocoon error page as if processing 
actually stopped!


I have a pipeline which aggregates several other pipelines and then 
writes the generated content to disk. If there is an exception in one of 
the aggregate parts I need the sitemap processing to stop and handle the 
exception appropriately. Instead the generated content, which has 
errored and therefore invalid, is still written to disk. If I remove the 
aggregate pipeline and just use a regular generator the handle-errors is 
respected correctly and processing stops before writing the content.


Am I misusing the  elements? Or is this the expected 
behavoir?



Thanks so much,

--
Justin Hannus
Software Engineer | Infrastructure | Lycos Inc.
[EMAIL PROTECTED]
[781] 370-2988





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Tab Order in CForms

2006-03-09 Thread Stewart, Gary

> I havn't ever tried it, but you can add the tabindex 
> attribute just like
> any other, for example:
> 
> 
>   
> 
> 
> The stylesheets simply copy over all the attributes they don't
> understand to the target input element.
> 
> There's also a shorter way of writing this, if you don't have 
> any nested
> elements in fi:styling (which is usually the case):
> 
> 

That looks like a good way to go about it; thanks. Gave it a go and it looks 
like it is working fine on the forms (though it might be a little tedious to 
change when I make changes to forms I might create a stylesheet to automate 
adding the attributes to widgets; I can post it when I've done it and if anyone 
else is interested. 

However I'd still like to know how I can get access to the cocoon resource link 
since I was also looking at changing the HTMLArea (and possibly replacing it 
with Xinha). 

Thanks,

Gary

*
The information contained in this message may be confidential or 
legally privileged and is intended for the addressee only, If you 
have received this message in error or there are any problems, 
please notify the originator immediately. The unauthorised use, 
disclosure, copying or alteration of this message is 
strictly forbidden.
*


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Tab Order in CForms

2006-03-09 Thread Bruno Dumon
On Thu, 2006-03-09 at 15:58 +, Stewart, Gary wrote:
> Does anyone know how to change the tab order in CForms? I was hoping
> to change it so it ignores the links (such as the help and error
> links) until it gets all the way to the bottom of the form. I'd assume
> you'd do this by altering the tab order in the final HTML form. I
> figure I should be looking at the forms styling to do this. I can't
> actually find where forms-page-styling.xsl and
> forms-advanced-field-styling.xsl are located though. Any clue as to
> where to look and maybe how to implement this?
> 

I havn't ever tried it, but you can add the tabindex attribute just like
any other, for example:


  


The stylesheets simply copy over all the attributes they don't
understand to the target input element.

There's also a shorter way of writing this, if you don't have any nested
elements in fi:styling (which is usually the case):



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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Tab Order in CForms

2006-03-09 Thread Stewart, Gary
Does anyone know how to change the tab order in CForms? I was hoping to change 
it so it ignores the links (such as the help and error links) until it gets all 
the way to the bottom of the form. I'd assume you'd do this by altering the tab 
order in the final HTML form. I figure I should be looking at the forms styling 
to do this. I can't actually find where forms-page-styling.xsl and 
forms-advanced-field-styling.xsl are located though. Any clue as to where to 
look and maybe how to implement this?

Thanks,

Gary

*
The information contained in this message may be confidential or 
legally privileged and is intended for the addressee only, If you 
have received this message in error or there are any problems, 
please notify the originator immediately. The unauthorised use, 
disclosure, copying or alteration of this message is 
strictly forbidden.
*


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: fop 0.91 beta //Serializer

2006-03-09 Thread Andrew Savory

Hi,

Kai Mütz wrote:

I have attached a simple FopSerializer class which uses the 0.91 beta API.
Very similar to the one described in
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=114175770501836&w=4 but can
be configured by a configuration file like the "old" FOPSerializer.


Please submit this via Jira (http://issues.apache.org/jira/).

Thanks,

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/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]