RE: FW: Tapestry 3.0.4..not on mirrors
Nick, Thanks for pointing that out, I finally found the e-mail trail. I decided that I couldn't take a chance on 3.0.4 and reverted back to 3.0.3. I guess we are done with 3.x and will wait for 5.x or the next great GUI Framework. Tapestry has been fun and very interesting. regards, Mark Mark J. Stang Senior Engineer/Architect office: +1 303.468.2900 mobile: +1 303.507.2833 Ping Identity -Original Message- From: Nick Westgate [mailto:[EMAIL PROTECTED] Sent: Tue 1/30/2007 8:10 PM To: Tapestry users Subject: Re: FW: Tapestry 3.0.4..not on mirrors Hi Mark. I'm referring to this thread: "3.0.4 and repetitive method name/signature problem (class enhancement)" http://thread.gmane.org/gmane.comp.java.tapestry.user/43121 Take it to the dev list when you've read that. (I'm not a dev, so as to who is managing 3 now ...) Cheers, Nick. Mark Stang wrote: > Nick, > I did a quick look and only saw references to 4.x. If 3.0.4 is not the > current release, then why does the Tapestry Web site have it listed as such? > > http://tapestry.apache.org/tapestry3/ > > Who is managing this? > > thanks, > > Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: Tapestry 3.0.4..not on mirrors
Hi Mark. I'm referring to this thread: "3.0.4 and repetitive method name/signature problem (class enhancement)" http://thread.gmane.org/gmane.comp.java.tapestry.user/43121 Take it to the dev list when you've read that. (I'm not a dev, so as to who is managing 3 now ...) Cheers, Nick. Mark Stang wrote: Nick, I did a quick look and only saw references to 4.x. If 3.0.4 is not the current release, then why does the Tapestry Web site have it listed as such? http://tapestry.apache.org/tapestry3/ Who is managing this? thanks, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Back button = no cycle
I've run into an interesting issue with a page that worked in Tapestry 3.1 that now has a problem in Tapestry 4.1. The first time I arrive at a page via a DirectLink that has a contrib:Table on it, it works fine, but if I click the back button and then link to the page again, it complains of a NullPointerException while trying to read the OGNL expression tableColumnIterator on line 51 of TableColumns.jwc. Interestingly, this *doesn't* happen if you turn off page caching. java.lang.NullPointerException Stack Trace: * org.apache.tapestry.contrib.table.components.AbstractTableViewComponent.getTableModelSource(AbstractTableViewComponent.java:35) * org.apache.tapestry.contrib.table.components.TableColumns.getTableColumnIterator(TableColumns.java:95) * sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) * sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) * sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) * java.lang.reflect.Method.invoke(Method.java:585) * ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:491) * ognl.OgnlRuntime.getMethodValue(OgnlRuntime.java:904) * ognl.ObjectPropertyAccessor.getPossibleProperty(ObjectPropertyAccessor.java:54) * ognl.ObjectPropertyAccessor.getProperty(ObjectPropertyAccessor.java:122) * ognl.OgnlRuntime.getProperty(OgnlRuntime.java:1616) * ognl.ASTProperty.getValueBody(ASTProperty.java:96) * ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) * ognl.SimpleNode.getValue(SimpleNode.java:210) * ognl.Ognl.getValue(Ognl.java:333) * ognl.Ognl.getValue(Ognl.java:310) * org.apache.tapestry.services.impl.ExpressionEvaluatorImpl.readCompiled(ExpressionEvaluatorImpl.java:102) * $ExpressionEvaluator_1107562b92d.readCompiled($ExpressionEvaluator_1107562b92d.java) * org.apache.tapestry.binding.ExpressionBinding.resolveExpression(ExpressionBinding.java:110) * org.apache.tapestry.binding.ExpressionBinding.getObject(ExpressionBinding.java:103) * org.apache.tapestry.components.ForBean.evaluateSourceIterator(ForBean.java:603) * org.apache.tapestry.components.ForBean.getData(ForBean.java:252) * org.apache.tapestry.components.ForBean.renderComponent(ForBean.java:107) * org.apache.tapestry.AbstractComponent.render(AbstractComponent.java:674) * org.apache.tapestry.services.impl.DefaultResponseBuilder.render(DefaultResponseBuilder.java:131) * org.apache.tapestry.BaseComponent.renderComponent(BaseComponent.java:92) * org.apache.tapestry.contrib.table.components.TableColumns.renderComponent(TableColumns.java:145) * org.apache.tapestry.AbstractComponent.render(AbstractComponent.java:674) * org.apache.tapestry.services.impl.DefaultResponseBuilder.render(DefaultResponseBuilder.java:131) * org.apache.tapestry.AbstractComponent.renderBody(AbstractComponent.java:491) * org.apache.tapestry.components.Any.renderComponent(Any.java:50) * org.apache.tapestry.AbstractComponent.render(AbstractComponent.java:674) * org.apache.tapestry.services.impl.DefaultResponseBuilder.render(DefaultResponseBuilder.java:131) * org.apache.tapestry.AbstractComponent.renderBody(AbstractComponent.java:491) * org.apache.tapestry.components.RenderBody.renderComponent(RenderBody.java:41) * org.apache.tapestry.AbstractComponent.render(AbstractComponent.java:674) * org.apache.tapestry.services.impl.DefaultResponseBuilder.render(DefaultResponseBuilder.java:131) * org.apache.tapestry.AbstractComponent.renderBody(AbstractComponent.java:491) * org.apache.tapestry.components.Any.renderComponent(Any.java:50) * org.apache.tapestry.AbstractComponent.render(AbstractComponent.java:674) * org.apache.tapestry.services.impl.DefaultResponseBuilder.render(DefaultResponseBuilder.java:131) * org.apache.tapestry.BaseComponent.renderComponent(BaseComponent.java:92) * org.apache.tapestry.contrib.table.components.TableView.renderComponent(TableView.java:524) * org.apache.tapestry.AbstractComponent.render(AbstractComponent.java:674) * org.apache.tapestry.services.impl.DefaultResponseBuilder.render(DefaultResponseBuilder.java:131) * org.apache.tapestry.BaseComponent.renderComponent(BaseComponent.java:92) * org.apache.tapestry.AbstractComponent.render(AbstractComponent.java:674) * org.apache.tapestry.services.impl.DefaultResponseBuilder.render(DefaultResponseBuilder.java:131) * org.apache.tapestry.AbstractComponent.renderBody(AbstractComponent.java:491) * org.apache.tapestry.components.RenderBody.renderComponent(RenderBody.java:41) * org.apache.tapestry.AbstractComponent.render(AbstractComponent.java:674) * org.apache.tapestry.services.impl.DefaultResponseBuilder.render(DefaultResponseBuilder.java:131) * org.apache.tapestry.AbstractComponent.renderBody(AbstractComponent.java:491) * org.apache.tapestry.components.Any.renderComponent(Any.java:50)
Re: Should @Insert encode whitespace?
http://tapestry.apache.org/tapestry4.1/components/general/insert.html
Use the format parameter and provide it with a SpaceToNBSPFormat (that
you also create)
Must leave raw to true.
Wes Bramhall wrote:
I have an app that displays a list of filenames to the user. I'm looping
over a list of File objects and displaying the names using an insert
component. Here's a barebones example:
It is possible to have filenames like "A B", "A B", and "AB".
Sent to the insert component, they get rendered as "A B", "A B", and
"AB" in the HTML source but end up displayed as "A B", "A B", and "A
B" on the screen. Setting the raw attribute to true doesn't change this
behavior. Would it be reasonable to encode consecutive spaces as ?
Does anyone have a better idea?
For now I'll have to switch to the below code:
public String getSafeName()
{
return getLoopFile().getName().replace(" ", " ");
}
Thanks,
-Wes
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Should @Insert encode whitespace?
I have an app that displays a list of filenames to the user. I'm looping
over a list of File objects and displaying the names using an insert
component. Here's a barebones example:
It is possible to have filenames like "A B", "A B", and "AB".
Sent to the insert component, they get rendered as "A B", "A B", and
"AB" in the HTML source but end up displayed as "A B", "A B", and "A
B" on the screen. Setting the raw attribute to true doesn't change this
behavior. Would it be reasonable to encode consecutive spaces as ?
Does anyone have a better idea?
For now I'll have to switch to the below code:
public String getSafeName()
{
return getLoopFile().getName().replace(" ", " ");
}
Thanks,
-Wes
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax and popuplink error
Turns out this was actually a problem with a Border component and a
custom shell delegate - the Body component was not making it through
properly - all working now!
J
On 29-Jan-07, at 3:22 PM, Julian Wood wrote:
I have a div that is updated in response to an EventListener. This
is all fine.
I just added a DirectLink which uses a PopupLinkRenderer in that
div. All is still good.
When you click that link, I get a "popup_window not defined" error
in javascript.
I can see that the correct script is passed in the AJAX response:
href="javascript:popup_window();">+
// var newWindow = window.open('/medvr/app?
component=media.popupFullMediaViewer&page=ViewModule&service=direct&se
ssion=T&sp=12', 'MedVR Media Viewer',
'top=100,left=100,width=480,height=480,scrollbars=yes,resizable=no');
newWindow.focus();
}
//]]>
but is it not made available to my page?
Am I missing something?
Tried with 4.1.2-SNAPSHOT and 4.1.1.
Thanks.
J
--
Julian Wood <[EMAIL PROTECTED]>
Software Engineer
Teaching & Learning Centre
University of Calgary
http://tlc.ucalgary.ca
--
Julian Wood <[EMAIL PROTECTED]>
Software Engineer
Teaching & Learning Centre
University of Calgary
http://tlc.ucalgary.ca
Re: Feedback for the AcegiSpringJava5FormBased wiki page
Yea, i've noticed some of those too, esp. the basic authentication 'issue' As for loging out, there's a wiki page that describes this and other ways... But anyway, you can go ahead and edit the wiki page yourself and add these findings. They should prove useful and time-saving Jimr wrote: It's great to see this howto up on the wiki! I have been playing around with the example and I have a couple of suggestions to make. 1. The FormProcessingFilter service point is most likely not required. Since the actual authentication is done programatically through the Acegi API, it does not appear to use the FormProcessingFilter at all. When I take this code out, there is no change whatsoever to the behaviour of the app. 2. If a user navigates directly to the login page and logs in successfully, the savedRequest object will be null, resulting in a NullPointerException. I don't have a generic solution for this one yet. It depends on how the pages are set up. 3. Here is a snippet that could be added to the end of the page for people wondering how to Logout: Add the following code to any html page where you want a logout link to appear: Logout FYI this only works when using form based authentication through Tapestry. If you use Basic authentication, it will not. The root cause of this appears to be that Acegi maintains a session independently of Tapestry with Basic auth, because Tapestry is bypassed. When using Form based authentication, the ContextHolder's context gets tied to the Tapestry session, and is discarded when that session is destroyed. -- Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr Tapestry / Tacos developer Open Source / J2EE Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Feedback for the AcegiSpringJava5FormBased wiki page
It's great to see this howto up on the wiki! I have been playing around with the example and I have a couple of suggestions to make. 1. The FormProcessingFilter service point is most likely not required. Since the actual authentication is done programatically through the Acegi API, it does not appear to use the FormProcessingFilter at all. When I take this code out, there is no change whatsoever to the behaviour of the app. 2. If a user navigates directly to the login page and logs in successfully, the savedRequest object will be null, resulting in a NullPointerException. I don't have a generic solution for this one yet. It depends on how the pages are set up. 3. Here is a snippet that could be added to the end of the page for people wondering how to Logout: Add the following code to any html page where you want a logout link to appear: Logout FYI this only works when using form based authentication through Tapestry. If you use Basic authentication, it will not. The root cause of this appears to be that Acegi maintains a session independently of Tapestry with Basic auth, because Tapestry is bypassed. When using Form based authentication, the ContextHolder's context gets tied to the Tapestry session, and is discarded when that session is destroyed. -- View this message in context: http://www.nabble.com/Feedback-for-the-AcegiSpringJava5FormBased-wiki-page-tf3143789.html#a8714094 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tapestry prop: suggestion (or question)
Good point. They all inherit from CayenneDataObject. I'll try to give
that a test in a bit. Thanks!
The electronic mail message you have received and any files transmitted
with it are confidential and solely for the intended addressee(s)'s
attention. Do not divulge, copy, forward, or use the contents,
attachments, or information without permission of Fannie Mae.
Information contained in this message is provided solely for the purpose
stated in the message or its attachment(s) and must not be disclosed to
any third party or used for any other purpose without consent of Fannie
Mae. If you have received this message and/or any files transmitted with
it in error, please delete them from your system, destroy any hard
copies of them, and contact the sender.
-Original Message-
From: andreas a [mailto:[EMAIL PROTECTED] On Behalf Of andyhot
Sent: Tuesday, January 30, 2007 12:50 PM
To: Tapestry users
Subject: Re: Tapestry prop: suggestion (or question)
Gentry, Michael (Contractor) wrote:
> I had seen the null handlers before, but was trying to avoid
registering
> 100+ handlers. :-)
>
well, perhaps they all share a common super type...
> Thanks,
>
> /dev/mrg
>
>
>
> The electronic mail message you have received and any files
transmitted
> with it are confidential and solely for the intended addressee(s)'s
> attention. Do not divulge, copy, forward, or use the contents,
> attachments, or information without permission of Fannie Mae.
> Information contained in this message is provided solely for the
purpose
> stated in the message or its attachment(s) and must not be disclosed
to
> any third party or used for any other purpose without consent of
Fannie
> Mae. If you have received this message and/or any files transmitted
with
> it in error, please delete them from your system, destroy any hard
> copies of them, and contact the sender.
>
>
> -Original Message-
> From: andreas a [mailto:[EMAIL PROTECTED] On Behalf Of andyhot
> Sent: Tuesday, January 30, 2007 12:15 PM
> To: Tapestry users
> Subject: Re: Tapestry prop: suggestion (or question)
>
> Gentry, Michael (Contractor) wrote:
>
>> I've downloaded and tried out the prop: prefix extension from HLS.
>>
> One
>
>> thing I was *really* hoping for, compared to OGNL, is that it would
>> ignore null pointers, at least on reads.
>>
>
> OGNL has a feature called NullHandlers
>
> You contribute one to configuration point tapestry.ognl.NullHandlers
> like this
> object="instance:org.MyNullHandler"/>
>
> where MyNullHandler implements
> http://www.ognl.org/2.6.9/Documentation/javadoc/ognl/NullHandler.html
>
> So, if you have a RegisterPage that contains a path like
> user.department.name you have
> to register null handlers (could be the same one) for the following :
> RegisterPage (cause its user may be null),
> User (cause his department may be null)
>
>
>
>
>
>> I have report-type pages
>> (read-only) where I can sometimes have thousands of rows with 10-15
>> columns. Each of those columns currently has bulky cover methods
>>
> which
>
>> do NPE protection in case a relationship is missing (the actual
values
>> almost always come from a dotted path: foo.bar.baz.status, and OGNL
>>
> will
>
>> blow up if "bar" is null). I was hoping the prop: extension would
>> handle this, but it seems to work just like OGNL if it hits a null.
>>
> If
>
>> something doesn't exist, I'm pretty happy with just getting a null
>>
> back
>
>> and displaying nothing.
>>
>> I played with the code a bit and this seems to work if you edit
>> PropertyAccessorBinding.java and change the getObject() method:
>>
>> public Object getObject()
>> {
>> return _accessor.readProperty();
>> }
Re: Tapestry prop: suggestion (or question)
Gentry, Michael (Contractor) wrote:
I had seen the null handlers before, but was trying to avoid registering
100+ handlers. :-)
well, perhaps they all share a common super type...
Thanks,
/dev/mrg
The electronic mail message you have received and any files transmitted
with it are confidential and solely for the intended addressee(s)'s
attention. Do not divulge, copy, forward, or use the contents,
attachments, or information without permission of Fannie Mae.
Information contained in this message is provided solely for the purpose
stated in the message or its attachment(s) and must not be disclosed to
any third party or used for any other purpose without consent of Fannie
Mae. If you have received this message and/or any files transmitted with
it in error, please delete them from your system, destroy any hard
copies of them, and contact the sender.
-Original Message-
From: andreas a [mailto:[EMAIL PROTECTED] On Behalf Of andyhot
Sent: Tuesday, January 30, 2007 12:15 PM
To: Tapestry users
Subject: Re: Tapestry prop: suggestion (or question)
Gentry, Michael (Contractor) wrote:
I've downloaded and tried out the prop: prefix extension from HLS.
One
thing I was *really* hoping for, compared to OGNL, is that it would
ignore null pointers, at least on reads.
OGNL has a feature called NullHandlers
You contribute one to configuration point tapestry.ognl.NullHandlers
like this
object="instance:org.MyNullHandler"/>
where MyNullHandler implements
http://www.ognl.org/2.6.9/Documentation/javadoc/ognl/NullHandler.html
So, if you have a RegisterPage that contains a path like
user.department.name you have
to register null handlers (could be the same one) for the following :
RegisterPage (cause its user may be null),
User (cause his department may be null)
I have report-type pages
(read-only) where I can sometimes have thousands of rows with 10-15
columns. Each of those columns currently has bulky cover methods
which
do NPE protection in case a relationship is missing (the actual values
almost always come from a dotted path: foo.bar.baz.status, and OGNL
will
blow up if "bar" is null). I was hoping the prop: extension would
handle this, but it seems to work just like OGNL if it hits a null.
If
something doesn't exist, I'm pretty happy with just getting a null
back
and displaying nothing.
I played with the code a bit and this seems to work if you edit
PropertyAccessorBinding.java and change the getObject() method:
public Object getObject()
{
return _accessor.readProperty();
}
Re: Tapestry prop: suggestion (or question)
Sometimes it might make sense to have a setObject( ) with a little bit different behavior... namely, if elements of the property path are null then try to instantiate them, but ignore setObject( ) calls where the value to set is null and one of the property path elements is also null. I've taken this approach in the past with reflection-based bindings, and it's been pretty nice. On 1/30/07, Gentry, Michael (Contractor) <[EMAIL PROTECTED]> wrote: PS. I didn't alter setObject() ... I'd consider that an actual error if you were trying to set things through nulls.
RE: Tapestry prop: suggestion (or question)
I had seen the null handlers before, but was trying to avoid registering
100+ handlers. :-)
Thanks,
/dev/mrg
The electronic mail message you have received and any files transmitted
with it are confidential and solely for the intended addressee(s)'s
attention. Do not divulge, copy, forward, or use the contents,
attachments, or information without permission of Fannie Mae.
Information contained in this message is provided solely for the purpose
stated in the message or its attachment(s) and must not be disclosed to
any third party or used for any other purpose without consent of Fannie
Mae. If you have received this message and/or any files transmitted with
it in error, please delete them from your system, destroy any hard
copies of them, and contact the sender.
-Original Message-
From: andreas a [mailto:[EMAIL PROTECTED] On Behalf Of andyhot
Sent: Tuesday, January 30, 2007 12:15 PM
To: Tapestry users
Subject: Re: Tapestry prop: suggestion (or question)
Gentry, Michael (Contractor) wrote:
> I've downloaded and tried out the prop: prefix extension from HLS.
One
> thing I was *really* hoping for, compared to OGNL, is that it would
> ignore null pointers, at least on reads.
OGNL has a feature called NullHandlers
You contribute one to configuration point tapestry.ognl.NullHandlers
like this
where MyNullHandler implements
http://www.ognl.org/2.6.9/Documentation/javadoc/ognl/NullHandler.html
So, if you have a RegisterPage that contains a path like
user.department.name you have
to register null handlers (could be the same one) for the following :
RegisterPage (cause its user may be null),
User (cause his department may be null)
> I have report-type pages
> (read-only) where I can sometimes have thousands of rows with 10-15
> columns. Each of those columns currently has bulky cover methods
which
> do NPE protection in case a relationship is missing (the actual values
> almost always come from a dotted path: foo.bar.baz.status, and OGNL
will
> blow up if "bar" is null). I was hoping the prop: extension would
> handle this, but it seems to work just like OGNL if it hits a null.
If
> something doesn't exist, I'm pretty happy with just getting a null
back
> and displaying nothing.
>
> I played with the code a bit and this seems to work if you edit
> PropertyAccessorBinding.java and change the getObject() method:
>
> public Object getObject()
> {
> return _accessor.readProperty();
> }
Re: Tapestry prop: suggestion (or question)
Gentry, Michael (Contractor) wrote:
I've downloaded and tried out the prop: prefix extension from HLS. One
thing I was *really* hoping for, compared to OGNL, is that it would
ignore null pointers, at least on reads.
OGNL has a feature called NullHandlers
You contribute one to configuration point tapestry.ognl.NullHandlers
like this
object="instance:org.MyNullHandler"/>
where MyNullHandler implements
http://www.ognl.org/2.6.9/Documentation/javadoc/ognl/NullHandler.html
So, if you have a RegisterPage that contains a path like
user.department.name you have
to register null handlers (could be the same one) for the following :
RegisterPage (cause its user may be null),
User (cause his department may be null)
I have report-type pages
(read-only) where I can sometimes have thousands of rows with 10-15
columns. Each of those columns currently has bulky cover methods which
do NPE protection in case a relationship is missing (the actual values
almost always come from a dotted path: foo.bar.baz.status, and OGNL will
blow up if "bar" is null). I was hoping the prop: extension would
handle this, but it seems to work just like OGNL if it hits a null. If
something doesn't exist, I'm pretty happy with just getting a null back
and displaying nothing.
I played with the code a bit and this seems to work if you edit
PropertyAccessorBinding.java and change the getObject() method:
public Object getObject()
{
return _accessor.readProperty();
}
Re: Tapestry prop: suggestion (or question)
The source for tapestry-prop is available.
If I were doing this, I would change how it generates code to check
for the nulls as it goes, rather than forcing an NPE. Further, when
accessing a property, there's always the potential that the terminal
property accessor method throws the NPE which you wouldn't want to
mask. So handle nulls by checking for nulls.
I don't believe in baking this into tapestry-prop, I try to code in
the "don't expect null, don't return null" vein. You can do a lot
with Collections.EMPTY_LIST and flyweight placeholders to prevent
NPEs.
On 1/30/07, Gentry, Michael (Contractor) <[EMAIL PROTECTED]> wrote:
I've downloaded and tried out the prop: prefix extension from HLS. One
thing I was *really* hoping for, compared to OGNL, is that it would
ignore null pointers, at least on reads. I have report-type pages
(read-only) where I can sometimes have thousands of rows with 10-15
columns. Each of those columns currently has bulky cover methods which
do NPE protection in case a relationship is missing (the actual values
almost always come from a dotted path: foo.bar.baz.status, and OGNL will
blow up if "bar" is null). I was hoping the prop: extension would
handle this, but it seems to work just like OGNL if it hits a null. If
something doesn't exist, I'm pretty happy with just getting a null back
and displaying nothing.
I played with the code a bit and this seems to work if you edit
PropertyAccessorBinding.java and change the getObject() method:
public Object getObject()
{
return _accessor.readProperty();
}
Re: Dojo components deprecated in Tap 4.1.1 ?
Stephane Decleire wrote: Why most of the Dojo components are marked as deprecated in Tap 4.1.1 ? It was decided that Tapestry will not directly support all those components + they were simply an undocumented experiment + will be removed in 4.1.2 If i need a TitlePane Dojo component in Tapestry, what is the new approach to implement it ? http://tacos.sourceforge.net/tacos4.1/tacos-core/ Thanks in advance. -- Stéphane Decleire -- Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr Tapestry / Tacos developer Open Source / J2EE Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: FW: Tapestry 3.0.4..not on mirrors
Nick, I did a quick look and only saw references to 4.x. If 3.0.4 is not the current release, then why does the Tapestry Web site have it listed as such? http://tapestry.apache.org/tapestry3/ Who is managing this? thanks, Mark Mark J. Stang Senior Engineer/Architect office: +1 303.468.2900 mobile: +1 303.507.2833 Ping Identity -Original Message- From: Nick Westgate [mailto:[EMAIL PROTECTED] Sent: Mon 1/29/2007 11:56 PM To: Tapestry users Subject: Re: FW: Tapestry 3.0.4..not on mirrors Hi Mark. If you aren't aware of the threading bug in 3.04 then please search the dev list for the last 3.04 thread. Cheers, Nick. Mark Stang wrote: > All, > We were looking to upgrade from 3.03. to 3.04 and it appears that 3.04 isn't > on the mirrors. > > Thoughts? > > Mark J. Stang > Senior Engineer/Architect > office: +1 303.468.2900 > mobile: +1 303.507.2833 > Ping Identity > > > > -Original Message- > From: Dave Smith > Sent: Mon 1/29/2007 6:48 AM > To: Mark Stang > Subject: Tapestry 3.0.4..not on mirrors > > I was going to upgrade to 3.0.4 this morning, but it's not on any of the > Apache mirrors. Care to inquire on the list as to what's going on? > > Thx. > > D. > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exception when trying to configure tapestry-acegi.jar
I believe you need hivemind-utils.jar in your classpath. On 1/30/07, jake123 <[EMAIL PROTECTED]> wrote: Hi, I have some problems when I try to use the tapestry-acegi.jar. My Jboss server starts up fine without any exceptions, but as soon as I try to access my application I get this exception: 11:07:48,750 ERROR [[/]] mycompany: ServletException javax.servlet.ServletException: Unable to construct service tapestry.acegi.ExceptionTranslationFilter: Error building se rvice tapestry.acegi.ExceptionTranslationFilter: Could not load class com.javaforge.tapestry.acegi.filter.ExceptionTrans lationFilter from WebappClassLoader delegate: false repositories: --> Parent Classloader: [EMAIL PROTECTED] : com/javaforge/hivemind/util/HiveMindService at org.apache.tapestry.services.impl.WebRequestServicerPipelineBridge.service(WebRequestServicerPipelineBridge.j ava:60)... the entire Exception is in the attached file http://www.nabble.com/file/6115/exception.txt exception.txt In out hivemodule.xml we have this code: In our web.xml we have this: MyCompany org.apache.tapestry.ApplicationServlet 0 MyCompany /index.html MyCompany *.html MyCompany *.direct MyCompany *.sdirect MyCompany *.svc In our spring applicationContext.xml we have: SELECT user_name as username, user_password as password, enabled as ENABLED FROM app_user WHERE user_name=? SELECT user_name as username, user_role as authority FROM app_user_role WHERE user_name=? We are using the folloing jar files for tapestry-ageci: tapestry-acegi-0.1-20070126.164757-10.jar hivemind-acegi-dao-0.1-20060608.022406-1.jar hivemind-acegi-0.1-20060607.122705-3.jar Does anybody know what we are doing wrong? Thanks, Jacob -- View this message in context: http://www.nabble.com/Exception-when-trying-to-configure-tapestry-acegi.jar-tf3142373.html#a8709323 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Exception when trying to configure tapestry-acegi.jar
Hi, I have some problems when I try to use the tapestry-acegi.jar. My Jboss server starts up fine without any exceptions, but as soon as I try to access my application I get this exception: 11:07:48,750 ERROR [[/]] mycompany: ServletException javax.servlet.ServletException: Unable to construct service tapestry.acegi.ExceptionTranslationFilter: Error building se rvice tapestry.acegi.ExceptionTranslationFilter: Could not load class com.javaforge.tapestry.acegi.filter.ExceptionTrans lationFilter from WebappClassLoader delegate: false repositories: --> Parent Classloader: [EMAIL PROTECTED] : com/javaforge/hivemind/util/HiveMindService at org.apache.tapestry.services.impl.WebRequestServicerPipelineBridge.service(WebRequestServicerPipelineBridge.j ava:60)... the entire Exception is in the attached file http://www.nabble.com/file/6115/exception.txt exception.txt In out hivemodule.xml we have this code: In our web.xml we have this: MyCompany org.apache.tapestry.ApplicationServlet 0 MyCompany /index.html MyCompany *.html MyCompany *.direct MyCompany *.sdirect MyCompany *.svc In our spring applicationContext.xml we have: SELECT user_name as username, user_password as password, enabled as ENABLED FROM app_user WHERE user_name=? SELECT user_name as username, user_role as authority FROM app_user_role WHERE user_name=? We are using the folloing jar files for tapestry-ageci: tapestry-acegi-0.1-20070126.164757-10.jar hivemind-acegi-dao-0.1-20060608.022406-1.jar hivemind-acegi-0.1-20060607.122705-3.jar Does anybody know what we are doing wrong? Thanks, Jacob -- View this message in context: http://www.nabble.com/Exception-when-trying-to-configure-tapestry-acegi.jar-tf3142373.html#a8709323 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reading page specifications... *without* loading the page
We solved this a number of ways, depending upon particular context
within our app. Acegi was unable to satisfy all of our security
requirements, so we went with a custom solution from top to bottom,
and one of our requirements was identical to yours. The set of roles
and per-page permission for each role are loaded into a data structure
rather than parsed out of the page specification, in our case. This
gives us the benefit of being able to use permissions without
redeploying the app. You could choose to populate your data structure
via a declarative environment such as a spring context, hivemind
config, external config file, database, etc, so it is pretty flexible
in that regard. In our case, the data structure is a spring bean
which is injected into the page and then passed into components via a
parameter.
Within tapestry, we implemented the following -
There's an AuthorizationDelegate injected into any page which is
accessed within the pageValidate method. It checks the currently
logged-in user and its assigned roles against the roles allowed to
load the page (and in our case, a mode - read or write). If they fail
auth, they are redirected away. Within templates, we use a tag
which can conditionally include parts of a template based on
whether a user is authorized to see a section (we actually have
per-property r/w permissions on each entity, so every form field is
wrapped in an IfAuth tag, usually within a subclass of the original
tapestry component). We have subclassed ExternalLink and PageLink so
that if the current user is not authorized, the link renders
differently (and we have various modes, depending upon context). Our
IfAuth tag actually works much like if/elseif/else in that you can
cascade through conditionals depending upon how previous conditions
evaluated. This allows us to have alternative renditions of a
template area based on granted permission.
Since we have read/write permissions on individual properties of
entities in the ui based on role, but we also have per-entity
read/write permissions assigned to individual users, we really weren't
able to use Acegi. Acegi wanted us to do lots of things up in the
service layer that were far more effectively handled down in the data
mapping layer. We use hibernate filters to ensure that only objects
assigned to the current user are loaded, modified, or stored. We use
an AOP interceptor to inject the appropriate filters on any service
method calls. All that necessitated a non-Acegi solution, which just
couldn't do what we wanted efficiently. By using filters and AOP and
subclassing various input field components, we were able to make very
minimal changes to the service or data access layers and kept changes
to our ui layer to a bare minimum (the entire security layer was added
on after initial application development, since it was not spec'd
before we had to have the first internal-use-only release out the
door). I can think of cleaner solutions if I was building an app to
support that security model from scratch, but our solution wound up
being very flexible with minimal invasiveness into an existing app.
To be honest, the saving grace for our app was that, because we had
very consistent layout for each input component, we created a wrapper
component which would determine the type of input field to render
based on the type of the property that was bound to it (Kind of like
BeanForm, but for an individual property instead of an entire Bean,
giving us more control over layout and ajax fanciness). Booleans get
checkboxes, lists get select drop downs or palettes, strings get
textboxes, etc. This enabled us to just throw an IfAuth tag around
the entire template contents for the wrapper component in order to
conditionally include a field based on role permissions. With that
single tag, we were able to apply role-based authorization to about
85% of our application. Slapping IfAuth tags around individual menu
items in the main menu took us to about 95%. The remaining 5%
consisted of fields which didn't use our wrapper component and
required individual IfAuth conditionals and links which were modified
to use subclass versions of the link components that conditionally
include the link depending upon authorization. We are now free to
build a UI to modify the permissions data structure on the fly, which
is also very useful to our organization.
--sam
On 1/30/07, Hugo Palma <[EMAIL PROTECTED]> wrote:
Ok. If you really want to go ahead with page spec parsing i guess you
can use the servlet context to find the spec file and then you'll have
to parse it yourself. You can inject the servlet context adding this to
your pages base class:
@InjectObject("service:tapestry.globals.ServletContext")
public abstract ServletContext getServletContext();
Robert J. Walker wrote:
> Yeah, we've been considering Acegi, but that's a little more long-range. The
only issue I have with using annotations for this is that I would have to create a
c
Re: Change to validation.js
https://www.secpay.com/secnet/signup.html I modified validation.js so the error message are dispalyed right below the fild in error This project is using Tapestry 3.0.4, but the concept should be the same Shuang -- View this message in context: http://www.nabble.com/Change-to-validation.js-tf3142229.html#a8709164 Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tapestry prop: suggestion (or question)
Please ignore the hyperlink that showed up in the code snippet... It
wasn't there when I was typing the e-mail. Gotta love MS. :-)
The electronic mail message you have received and any files transmitted
with it are confidential and solely for the intended addressee(s)'s
attention. Do not divulge, copy, forward, or use the contents,
attachments, or information without permission of Fannie Mae.
Information contained in this message is provided solely for the purpose
stated in the message or its attachment(s) and must not be disclosed to
any third party or used for any other purpose without consent of Fannie
Mae. If you have received this message and/or any files transmitted with
it in error, please delete them from your system, destroy any hard
copies of them, and contact the sender.
-Original Message-
From: Gentry, Michael (Contractor) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 30, 2007 9:03 AM
To: Tapestry users
Subject: Tapestry prop: suggestion (or question)
I've downloaded and tried out the prop: prefix extension from HLS. One
thing I was *really* hoping for, compared to OGNL, is that it would
ignore null pointers, at least on reads. I have report-type pages
(read-only) where I can sometimes have thousands of rows with 10-15
columns. Each of those columns currently has bulky cover methods which
do NPE protection in case a relationship is missing (the actual values
almost always come from a dotted path: foo.bar.baz.status, and OGNL will
blow up if "bar" is null). I was hoping the prop: extension would
handle this, but it seems to work just like OGNL if it hits a null. If
something doesn't exist, I'm pretty happy with just getting a null back
and displaying nothing.
I played with the code a bit and this seems to work if you edit
PropertyAccessorBinding.java and change the getObject() method:
public Object getObject()
{
return _accessor.readProperty();
}
Tapestry prop: suggestion (or question)
I've downloaded and tried out the prop: prefix extension from HLS. One
thing I was *really* hoping for, compared to OGNL, is that it would
ignore null pointers, at least on reads. I have report-type pages
(read-only) where I can sometimes have thousands of rows with 10-15
columns. Each of those columns currently has bulky cover methods which
do NPE protection in case a relationship is missing (the actual values
almost always come from a dotted path: foo.bar.baz.status, and OGNL will
blow up if "bar" is null). I was hoping the prop: extension would
handle this, but it seems to work just like OGNL if it hits a null. If
something doesn't exist, I'm pretty happy with just getting a null back
and displaying nothing.
I played with the code a bit and this seems to work if you edit
PropertyAccessorBinding.java and change the getObject() method:
public Object getObject()
{
return _accessor.readProperty();
}
Dojo components deprecated in Tap 4.1.1 ?
Why most of the Dojo components are marked as deprecated in Tap 4.1.1 ? If i need a TitlePane Dojo component in Tapestry, what is the new approach to implement it ? Thanks in advance. -- Stéphane Decleire
Change to validation.js
Hello, I'm watching at the clientValidation for Tapestry 4.1.1 I see that when there is an exception a dojo dialog is exposed to the user and a class fieldMissing or fieldInvalid is added to the relative component. When the user closes the dialog he has no more information about the exception on the input element. I think it could be nice to keep the exception information tied to the field with a dojo popup so that the user has not to remember what went wrong with the relative field. Does anybody think this change may be interesting (I'd like to keep the dialog information and add the tooltip info)? I could post here this change. Ciao, kiuma
Re: Reading page specifications... *without* loading the page
Ok. If you really want to go ahead with page spec parsing i guess you
can use the servlet context to find the spec file and then you'll have
to parse it yourself. You can inject the servlet context adding this to
your pages base class:
@InjectObject("service:tapestry.globals.ServletContext")
public abstract ServletContext getServletContext();
Robert J. Walker wrote:
Yeah, we've been considering Acegi, but that's a little more long-range. The
only issue I have with using annotations for this is that I would have to
create a class for every page in the app. As it stands right now, I'm able to
reuse the same class for a fair number of my simpler pages without having a
subclass for each one.
Robert J. Walker
-Original Message-
From: Hugo Palma [mailto:[EMAIL PROTECTED]
Sent: Monday, January 29, 2007 4:53 PM
To: Tapestry users
Subject: Re: Reading page specifications... *without* loading the page
Without really answering your question, have you looked at
tapestry-acegi (http://www.carmanconsulting.com/tapestry-acegi/).
The Secured annotation is a life saver..
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Tapestry 4.1 to 4.1.1 upgrade
Hi everyone, Have to quickly say that the Tapestry Dev. team are doing a sterling job of improving the framework, thanks for all your hard work. I Just completed a fairly smooth upgrade, I am quite impressed with the noticeable performance improvements since 4.0 Syntax and error checking seems to be a lot stricter in 4.1.1, this is a good thing, so If you are upgrading be sure to close every tag, even or , they have to become and ... I was getting this warning: "No ajax-response elements recieved." (received is a minor typo by the way), and firebug showed: "mismatched tag. Expected: ." or "" Kind regards, Peter -- Peter Stavrinides Albourne Partners (Cyprus) Ltd Tel: +357 22 750652 If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tap 4.1.2 Snapshot : Using Dojo TabContainer
I have posted an answer in Tapestry mailing list. http://article.gmane.org/gmane.comp.java.tapestry.user/44693/match=dojotabs Also, there is an online example (with source code) at my site http://lombok.demon.co.uk/tapestry4Demo/app Shing --- kmadha <[EMAIL PROTECTED]> wrote: > Shing Hing Man yahoo.com> writes: > > > > > I have noticed the static way of defining a Dojo > > TabContainer > > in a Tapestry page html template does not work. > > > Hello, > I am facing quite similar problem. > if I use the tacos:DojoTabs then the tabs are > visible but the tab content is > not visible. > Can you please help me in this? > > > > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > Home page : http://uk.geocities.com/matmsh/index.html ___ Inbox full of unwanted email? Get leading protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tap 4.1.2 Snapshot : Using Dojo TabContainer
Shing Hing Man yahoo.com> writes: > > I have noticed the static way of defining a Dojo > TabContainer > in a Tapestry page html template does not work. Hello, I am facing quite similar problem. if I use the tacos:DojoTabs then the tabs are visible but the tab content is not visible. Can you please help me in this? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
@For component with iterator
Can anyone give a simple example of using @For component with source as an String Iterator(Iterator)? Thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
