RE: Strange Behavior with inputTextarea component

2007-02-12 Thread Gary VanMatre
From: [EMAIL PROTECTED] 
Hi
The magic is a missing attribute: allowBody
  form
   textarea jsfid=textAreaTest allowBody=false This 
 is a mockup./textarea
  /form


You can also use another Clay functionality

 
Or, you can put this attribute in the XML config.
 
component jsfid=textAreaTest extends=inputTextarea id=textAreaTest 
allowBody=false
attributes
   set name=value value=Test was successful. /
/attributes
/component
 
This was David Geary's idea originally.  I guess Tapestry has a similar 
concept.  
In the future, I'd like to provide a annotation replacement for this XML stuff.
 
After all, we need to keep up with Tapestry 5.
 
 

form
   textarea jsfid=textAreaTest
!-- ### clay:remove ### --
This is a mockup.
!-- ### /clay:remove ### --
   /textarea
  /form

Hermod

 
snippet/
 
From: Richard Eggert [mailto:[EMAIL PROTECTED]
Sent: Monday, February 12, 2007 3:55 AM
To: user@shale.apache.org
Subject: Strange Behavior with inputTextarea component


I've been trying to teach myself how to use Clay (despite the atrocious lack 
of 
available documentation).  
 

 
Well, I've been lobbying for some time for David to do some more writing on 
Clay.  The top half of the Clay site documentation was written by David.  I 
guess he's busy making money or something?
 
Anyway, *hopefully* the new Shale in Action book will have some material on 
Clay.
 
In the process of doing this, I put together a very 
simple hello world style application.  However, the behavior is not as 
expected, and I'm not sure whether I'm doing something wrong or there's an 
actual bug in Clay.
 

BTW, Hermod, thanks for all your help!
 
Gary

 

RE: Strange Behavior with inputTextarea component

2007-02-12 Thread Richard Eggert
Thanks.  That fixed the problem.  What I actually ended up doing was this:

component jsfid=myTextarea extends=inputTextarea id=myTextarea 
allowBody=false /
component jsfid=textAreaTest extends=myTextarea id=textAreaTest
attributes
set name=value value=Test was successful. /
/attributes
/component


This allows me to reuse the de-bodified textarea without any additional work. 
 

I'm not quite sure why this isn't the default behavior for inputTextarea, 
though.  What possible reason could there be for someone to want to use the 
current default behavior (i.e., to have the body contents rendered AFTER the 
/textarea, such that it becomes regular text when rendered, whereas it is the 
contents of a textarea field during mockup)?  If someone really wanted that to 
happen, they could write it that way in their original HTML.  It seems like it 
would save a lot of people some extra work if inputTextArea were defined with 
allowBody=false set by default (still allowing allowBody=true to be 
manually set by those weirdos that really want that behavior).

Anyway, thanks for your help! :-)


Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com



-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sent: Mon 2/12/2007 11:28 AM
To: user@shale.apache.org
Subject: RE: Strange Behavior with inputTextarea component
 
From: [EMAIL PROTECTED] 
Hi
The magic is a missing attribute: allowBody
  form
   textarea jsfid=textAreaTest allowBody=false This 
 is a mockup./textarea
  /form


You can also use another Clay functionality

 
Or, you can put this attribute in the XML config.
 
component jsfid=textAreaTest extends=inputTextarea id=textAreaTest 
allowBody=false
attributes
   set name=value value=Test was successful. /
/attributes
/component
 
This was David Geary's idea originally.  I guess Tapestry has a similar 
concept.  
In the future, I'd like to provide a annotation replacement for this XML stuff.
 
After all, we need to keep up with Tapestry 5.
 
 

form
   textarea jsfid=textAreaTest
!-- ### clay:remove ### --
This is a mockup.
!-- ### /clay:remove ### --
   /textarea
  /form

Hermod

 
snippet/
 
From: Richard Eggert [mailto:[EMAIL PROTECTED]
Sent: Monday, February 12, 2007 3:55 AM
To: user@shale.apache.org
Subject: Strange Behavior with inputTextarea component


I've been trying to teach myself how to use Clay (despite the atrocious lack 
of 
available documentation).  
 

 
Well, I've been lobbying for some time for David to do some more writing on 
Clay.  The top half of the Clay site documentation was written by David.  I 
guess he's busy making money or something?
 
Anyway, *hopefully* the new Shale in Action book will have some material on 
Clay.
 
In the process of doing this, I put together a very 
simple hello world style application.  However, the behavior is not as 
expected, and I'm not sure whether I'm doing something wrong or there's an 
actual bug in Clay.
 

BTW, Hermod, thanks for all your help!
 
Gary

 




RE: Strange Behavior with inputTextarea component

2007-02-11 Thread hermod.opstvedt
Hi

The magic is a missing attribute: allowBody

form
textarea jsfid=textAreaTest allowBody=false This 
is a mockup./textarea
/form

You can also use another Clay functionality

form
textarea jsfid=textAreaTest
!-- ### clay:remove ### --
This is a mockup.
!-- ### /clay:remove ### --
/textarea
/form

Hermod

-Original Message-
From: Richard Eggert [mailto:[EMAIL PROTECTED]
Sent: Monday, February 12, 2007 3:55 AM
To: user@shale.apache.org
Subject: Strange Behavior with inputTextarea component


I've been trying to teach myself how to use Clay (despite the atrocious lack of 
available documentation).  In the process of doing this, I put together a very 
simple hello world style application.  However, the behavior is not as 
expected, and I'm not sure whether I'm doing something wrong or there's an 
actual bug in Clay.

My welcome page, index.jsp, contains a redirect to /test.faces.

test.faces maps to test.jsp, which looks like this:

%@ taglib prefix=f uri=http://java.sun.com/jsf/core%
%@ taglib prefix=sh uri=http://shale.apache.org/clay; %
f:view
sh:clay 
id=testPage 
jsfid=/test.html 
/
/f:view


test.html itself looks like this:

!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01//EN' 
'http://www.w3.org/TR/html4/strict.dtd'
html
head
titleThis is a test/title
/head
body
form
textarea jsfid=textAreaTestThis is a 
mockup./textarea
/form
/body
/html


When viewed in a browser or the Preview pane of the Amateras HTML editor, the 
HTML file is (correctly) rendered as a single TEXTAREA entity with the text 
This is a mockup. as its contents.

My clay-config.xml looks like this:

?xml version=1.0 encoding=UTF-8?
!DOCTYPE view PUBLIC
-//Apache Software Foundation//DTD Shale Clay View Configuration 
1.0//EN
http://shale.apache.org/dtds/clay-config_1_0.dtd;

view
component jsfid=textAreaTest extends=inputTextarea 
id=textAreaTest
attributes
set name=value value=Test was successful. /
/attributes
/component
/view


When I deploy the application and load the page in my browser, the TEXTAREA is 
rendered with the text Test was successful. as its contents (as expected), 
but the text This is a mockup. also appears AFTER the TEXTAREA element as 
regular text, which seems like incorrect behavior.  Doing a View Source on 
the page yields the following:

!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01//EN' 
'http://www.w3.org/TR/html4/strict.dtd'
html
head
titleThis is a test/title
/head
body
form id=_id2 name=_id2 method=post 
action=/squadBB/test.faces enctype=application/x-www-form-urlencoded
textarea name=_id2:textAreaTest 
id=_id2:textAreaTestTest was successful./textareaThis is a mockup.
input type=hidden name=_id2_SUBMIT value=1 /input 
type=hidden name=jsf_sequence value=1 //form
/body
/html


Is this a bug, or am I doing something wrong?  It doesn't seem like Clay should 
be moving the contents of a TEXTAREA such that it is rendered after the tag 
(causing it to appear as regular text).

I'm using Shale v1.04 with MyFaces 1.1.4 on Tomcat 5.5.




Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com




* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that DnB NOR cannot
accept any payment orders or other legally binding correspondence with
customers as a part of an email. 

This email message has been virus checked by the anti virus programs used
in the DnB NOR Group.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *