Re: new submitType parameter
Jesse Kuhnert wrote: It is required with a default value, so no one actually ever needs to specify it if they don't want to. I wonder how I couldn't have noticed this... it must be from tiredness... sorry about that. Bernard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tacos4 Live Demo is down?
Hello, My colleague is doing Tapestry/JSF evaluation in terms of their suitability for his project. To support my argument, that Tapestry would be a great choice I wanted to show him some cool features, he asked about, that can be obtained in Tap 4 / 4.1 using Tacos. Unfortunately it seems that Tacos4 demo app is down for some reasons :/ Is it temporary? When the demo will be up? Or where can I find the up-to-date demo of Tacos? TIA, Bernard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tacos4 Live Demo is down?
I forgot to add that I'm talking about live demo referenced from Tacos home page http://tacos.sourceforge.net/ Demo link http://opencomponentry.com:8080/tacos/ regards, Bernard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tacos4 Live Demo is down?
Josh Long wrote: download tacos and the war for the demo is available ont he sam page from sourceforge as the tacos lib itself. plop it in a container and you're all set. ;-) Thanks. I've just noticed what is wrong. The links in tacos component reference are wrong. I.e. Dialog component page references Tacos Live demo, link points to: http://demo.opennotion.com/tacos4/core/DialogExample.html It *DOES NOT* work. However, the main site refrences live demo, as well but placed at address: http://opencomponentry.com:8080/tacos/ Only after pasting the link into mail client I've noticed that it is different from what I've tried on Dialog page. And it *DOES* work. Whoever is responsible for Tacos site, please take care of it. It took 4 posts to resolve this ;-) Best regards, Bernard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tacos4 Live Demo is down?
Bernard Lange wrote: I forgot to add that I'm talking about live demo referenced from Tacos home page http://tacos.sourceforge.net/ Demo link http://opencomponentry.com:8080/tacos/ Yeah right. As I wrote in other post. Above link is OK. But http://demo.opennotion.com/tacos4/core/DialogExample.html link referenced from Dialog component reference page is broken. regards, Bernard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: recursive rendering
Dan Adams wrote: Every once in a while I'll need to do some recursive rendering. Does anyone know of a simple example of this using @Block? We do it that way. This renders tree-like, no folding though, recursive structure of report groups containing other report groups (which are compound nodes) and reports (leafs). Root group is given as a parameter, but it may be as well page property with initial value set to sth. You also need some exit condition, which in this case is size of reportGroups property. Note that the group property is updated in the second loop so that the recursive call to groupBlock could render its children properly. Some styling has been removed for a sake of readability: *HTML template* span jwcid=@RenderBlock block=ognl:components.groupBlock/ block jwcid=[EMAIL PROTECTED] !-- current group name -- span jwcid=@Insert value=ognl:group.name / !-- list of children reports) -- loop jwcid=@Foreach source=ognl:group.reports value=ognl:report element=ul lispan jwcid=@Insert value=ognl:report.name //li /loop !-- render recursively child groups -- condition jwcid=@Conditional condition=ognl:group.reportGroups.size() 0 loop jwcid=@Foreach source=ognl:group.reportGroups value=ognl:group span jwcid=@RenderBlock block=ognl:components.groupBlock/ /loop /condition /block *JWCID* component-specification class=org.apache.tapestry.BaseComponent allow-body=no allow-informal-parameters=no parameter name=group type=YYY required=yes direction=auto / property-specification name=report type=XXX/ /component-specification best regards, Bernard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Basic HTTP Authentication in Tap 3 = Acegi + Spring ?
Hello all, My production system still runs on Tapestry 3.0.4/Hibernate/Spring. I would like to setup Basic HTTP Authentication scheme for some non-critical, but administrator-only pages (ie. usage stats etc.). For normal user pages we currently use authentication mechanism, but what I need is fast, non db authentication. My first thought is to use old-rusty HTTP Basic Authentication scheme. What is the easiest suggested way to do it in Tapestry? Can this be achieved with Acegi with Tapestry 3? How do I set up Acegi using just Spring? All of previous discussions on Acegi were in context of Tapestry 4, unfortunately (for me :) ) Any suggestions, help, guidance, links to threads I may have missed will be appreciated, Thanks in advance, Bernard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Basic HTTP Authentication in Tap 3 = Acegi + Spring ?
Hugo Palma wrote: I think the fastest way to achieve what you need would be to use declarative security(in the web.xml) together with friendly URLs. Ok. I've done it differently. As I don't want to rely on page urls (whether friendly or not) I've implemented simple authentication page validator. It is registered on particular pages and does the following: 1) If user sent 'Authorization' header, decode auth details and check if they're OK. If yes go to 4. If not go to 3. 2) If no 'Authorization' header found - go to 3; 3) Sent 401 server challenge with 'WWW-Authentication' header; Redirect to authentication required page. Fast and simple :-) Not super secure, but that is not what I needed. This could be improved with failed login counter to break the loop :-) Regards, Bernard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Order by which events and listeners are called
Rui Pacheco wrote: Hi all Hi, My problem is, pageValidate, the natural place to check whether the user has permissions to load that page or not, is being called before doLogin and this makes it impossible for the user to login. You mean that the form does not start rewinding cause listener in pageValidate redirected the user to login page? This is how we do it. Application pages have registered pageValidate authentication listener. If user is not authenticated, listener redirects him to Login page. Login page does have pageValidate authentication listener :-) regards, Bernard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Order by which events and listeners are called
Bernard Lange wrote: redirects him to Login page. Login page does have pageValidate Correction: Login page *DOES NOT* have such pageValidate authentication listener. Forgive me this important typo :) Cheers, Bernard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Order by which events and listeners are called
Rui Pacheco wrote:
I implement a class called AbstractWebPage that extends BasePage and I
store
all functionality common to webpages there.
I guess, as Geoff sugested, I'll created another abstract web page that
deals uniquely with pages that need authentication.
This is what I suggested too. If you've put your authentication listener
in AbstractWebPage then your Login page cannot extend it any more.
If you want authenticated pages and Login page share common
functionality you have to move the authentication listener down in the
class hierarchy i.e. to AbstractAuthenticatedWebPage.
This would look like this:
public class AbstractWebPage
extends BasePage
{
common functionality hoes here
}
public class AbstractAuthenticatedWebPage
extends AbstractWebPage
{
.. pageValidate authentication check listener goes here
}
public class LoginPage
extends AbstractWebPage
{
.. some login listener goes logic here - no auth check done
}
public class SomeAppPage
extends AbstractAuthenticatedWebPage
{
... application page that check whether user has logged in
}
Another approach is to create simple non-html component, lets call it
AuthenticationRequired and place it in pages which does require
authentication. This may be better than page hierarchy approach if only
some of your pages require authentication.
Such component can look like this:
public abstract class AuthenticationRequired
extends AbstractComponent
implements PageValidateListener
{
public void pageValidate(PageEvent event)
{
do some authentication check
and redirect conditionally to login page
}
protected void renderComponent(IMarkupWriter writer, IRequestCycle
cycle)
{
// Nothing to render
}
}
regards,
Bernard
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Order by which events and listeners are called
Rui Pacheco wrote: And this is another very good idea. But if I stick with the abstract authenticated class, I'll have to update code in one single place, while the component will force me to copy/paste it accross all the templates. Yes indeed. Decision is up to you, what's more convienient and maintainable in your app. If number of authenticated pages will grow, the inheritance approach may be better choice. Regards, Bernard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ValidationDelegate doesn't decorate
Christian Dutaret wrote: What I do is create a new instance of the delegate only if there isn't one yet, and make it available to the form component through a page property. You can make a delegate a page bean which would free you from managing delegate instance. bean name=delegate class=xx.xx.xx.StyledValidationDelegate / regards, Bernard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 3.0.4 and Friendly URLs patch problem
Bernard Lange wrote: 'http://localhost:8080/edu-high/oswiata/?sp=logo.gifsp=MDSUMGOESHERE' Correction. The link goes of course as: 'http://localhost:8080/edu-high/oswiata/asset.do?sp=logo.gifsp=MDSUMGOESHERE' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
