Re: [Catalyst] XSD Validation of Forms
Great input and insight, thanks! My comment was perhaps more oriented to using a common declarative validation idiom such as an xml schema because with this particular project, I found myself maintaining FormBuilder YAML files and XSDs. Then I decided to convert HTML to XML and use the common XSD for both. Since most decent XML parsers already perform the validation, and they are usually quite fast, I thought that perhaps something similar to the FormBuilder plug-in could be built that used an XML approach. I find your comments on JSON and model-to-DB very interesting but don't agree with all of it. I think that sane RDBMS modeling is still not going away for a while. regarding REST take a look at this project I'm working on and that is Catalyst-based: http://www.p2ee.org Cheers, Alejandro Imass On Mon, Aug 10, 2009 at 8:17 AM, John Napiorkowskijjn1...@yahoo.com wrote: --- On Thu, 8/6/09, Alejandro Imass alejandro.im...@gmail.com wrote: From: Alejandro Imass alejandro.im...@gmail.com Subject: [Catalyst] XSD Validation of Forms To: The elegant MVC web framework catalyst@lists.scsys.co.uk Date: Thursday, August 6, 2009, 12:15 PM I did something cool these days for a client and was thinking that perhaps might be a cool plugin for Catalyst. I created a B2B app for a client that has both HTML and XML API. So I decided to convert the HTML/XHTML requests to XML, the same XML format as the XML API and validate both with the same XSD. Laziness, of course, of having to maintain an HTML field validation scheme PLUS an XSD validation scheme using LibXML. Hope you're following me here... So, it occurred to me that perhaps XSD validations can be perhaps more useful and powerful than Formbuilder's declarative validation oin yaml. I did an xforms based project a few years ago and enjoyed working with the system but unfortunately true xforms support has lagged in all the browsers. There are plugins but nothing native. I think most people have settled on a 'best 80%' of features via ajax style libs. submitting forms via json is a somewhat similar approach, although not as clean as the xforms approach, but at least it works. I do think the best approach is going to end up being similar to the way we deploy and use DBIx::Class, where we generally first model in Perl and then deploy to the target database engine. In other words you model your user interface expectations and then render the type you want. I this this is going to be more flexible than systems that validate the other way around. Does anyone here think this might be interesting? Maybe it already exists, but the whole thing came out so cool, that I thought it might be useful for the Catalyst / Perl world in general. Although Perl has pretty good XML support, with multiple parsers, both DOM and SAX based, there doesn't seem to be strong excitement around it. I don't think most of the developers around here like XML based configuration files (think they are too verbose) and you don't see a lot of love for XSLT or similar. Again, I think it's about pragmatism, where JSON approaches get you most of the way for less effort. Also the XML camps seem to be somewhat offish to the Perl community. Maybe it's just me but seems like all the examples are Python or Java. There's a certain amount of academia driving XML, or big enterprises, and both groups tend to treat the Perl programming language as something left over rather than something to be excited about. Axkit is a web development system that's totally XML driven, you might want to take a look. Also part of your interest might fit well with the various REST projects going on. I think if you're approach is that XML is the transport rather than the framework you'd get more interest. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Loading template according to request path
Is there a presently existing mechanism which flexibly allows for template selection according to the request URI? For instance a request to www.myapp.com/somepage would set something like stash(template = 'somepage.tt') if the file exists and continue to be processed by the appropriate or default action. I wrote something which does this which I'm about to spend some time cleaning up and optimizing but don't want to be reinventing any wheels (especially likely smoother ones). ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Loading template according to request path
On Tue, Aug 11, 2009 at 12:09 PM, Matt Whipple m...@mattwhipple.com wrote: Is there a presently existing mechanism which flexibly allows for template selection according to the request URI? For instance a request to www.myapp.com/somepage would set something like stash(template = ' somepage.tt') if the file exists and continue to be processed by the appropriate or default action. I wrote something which does this which I'm about to spend some time cleaning up and optimizing but don't want to be reinventing any wheels (especially likely smoother ones). ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ This is the default behavior for View::TT, as it says in the POD: If a stash item isn't defined, then it instead uses the stringification of the action dispatched to (as defined by $c-action) in the above example, this would be message, but because the default is to append '.tt', it would load root/message.tt. Is that not what you wanted? -J ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Loading template according to request path
J. Shirley wrote: On Tue, Aug 11, 2009 at 12:09 PM, Matt Whipple m...@mattwhipple.com mailto:m...@mattwhipple.com wrote: Is there a presently existing mechanism which flexibly allows for template selection according to the request URI? For instance a request to www.myapp.com/somepage http://www.myapp.com/somepage would set something like stash(template = 'somepage.tt http://somepage.tt') if the file exists and continue to be processed by the appropriate or default action. I wrote something which does this which I'm about to spend some time cleaning up and optimizing but don't want to be reinventing any wheels (especially likely smoother ones). ___ List: Catalyst@lists.scsys.co.uk mailto:Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ This is the default behavior for View::TT, as it says in the POD: If a stash item isn't defined, then it instead uses the stringification of the action dispatched to (as defined by $c-action) in the above example, this would be |message|, but because the default is to append '.tt', it would load |root/message.tt http://message.tt|. Is that not what you wanted? -J That is matching according to action, I'm looking to match on path (without having to create logically redundant complementary actions). ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Loading template according to request path
On Tue, Aug 11, 2009 at 3:01 PM, Matt Whipple m...@mattwhipple.com wrote: J. Shirley wrote: On Tue, Aug 11, 2009 at 12:09 PM, Matt Whipple m...@mattwhipple.commailto: m...@mattwhipple.com wrote: Is there a presently existing mechanism which flexibly allows for template selection according to the request URI? For instance a request to www.myapp.com/somepage http://www.myapp.com/somepage would set something like stash(template = 'somepage.tt http://somepage.tt') if the file exists and continue to be processed by the appropriate or default action. I wrote something which does this which I'm about to spend some time cleaning up and optimizing but don't want to be reinventing any wheels (especially likely smoother ones). ___ List: Catalyst@lists.scsys.co.uk mailto:Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ This is the default behavior for View::TT, as it says in the POD: If a stash item isn't defined, then it instead uses the stringification of the action dispatched to (as defined by $c-action) in the above example, this would be |message|, but because the default is to append '.tt', it would load |root/message.tt http://message.tt|. Is that not what you wanted? -J That is matching according to action, I'm looking to match on path (without having to create logically redundant complementary actions). Well, you could be clever and do some kind of thing in an auto to do that -- fREW Schmidt http://blog.afoolishmanifesto.com ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Loading template according to request path
Well in Catalyst an action is usually mapped to a controller method,
so I really don't understand your request. Maybe this example will
help:
sub edit : Local {
my ( $self, $c ) = @_;
my $uri = URI-new($c-req-base);
# get whatever you want from the URI
my $auth = $uri-authority;
#do whatever you want with that info...
See perldoc URI
Best,
Alejandro Imass
On Tue, Aug 11, 2009 at 3:09 PM, Matt Whipplem...@mattwhipple.com wrote:
Is there a presently existing mechanism which flexibly allows for template
selection according to the request URI? For instance a request to
www.myapp.com/somepage would set something like stash(template =
'somepage.tt') if the file exists and continue to be processed by the
appropriate or default action.
I wrote something which does this which I'm about to spend some time
cleaning up and optimizing but don't want to be reinventing any wheels
(especially likely smoother ones).
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Loading template according to request path
On Tue, Aug 11, 2009 at 1:01 PM, Matt Whipple m...@mattwhipple.com wrote:
This is the default behavior for View::TT, as it says in the POD:
If a stash item isn't defined, then it instead uses the stringification of
the action dispatched to (as defined by $c-action) in the above example,
this would be |message|, but because the default is to append '.tt', it
would load |root/message.tt http://message.tt|.
Is that not what you wanted?
-J
That is matching according to action, I'm looking to match on path (without
having to create logically redundant complementary actions).
So, essentially, you have a separate path versus the action path, and want
it to default to the URI path and not the action Path?
Essentially:
sub end : Private ActionClass('RenderView') {
my ( $self, $c ) = @_;
$c-stash-{template} .= $c-req-uri-path . .tt;
}
Is this right? This seems like a decent enough configuration idea to have
directly in Catalyst::View::TT, rather than always pick the action.
-J
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Loading template according to request path
On Tue, Aug 11, 2009 at 1:34 PM, Alejandro Imass
alejandro.im...@gmail.comwrote:
Well in Catalyst an action is usually mapped to a controller method,
so I really don't understand your request. Maybe this example will
help:
sub edit : Local {
my ( $self, $c ) = @_;
my $uri = URI-new($c-req-base);
# get whatever you want from the URI
my $auth = $uri-authority;
#do whatever you want with that info...
See perldoc URI
$c-req-uri is a blessed URI object already, so you can just do
$c-req-uri-authority as well.
-J
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Loading template according to request path
On Tue, Aug 11, 2009 at 3:01 PM, Matt Whipple m...@mattwhipple.com mailto:m...@mattwhipple.com wrote: J. Shirley wrote: On Tue, Aug 11, 2009 at 12:09 PM, Matt Whipple m...@mattwhipple.com mailto:m...@mattwhipple.com mailto:m...@mattwhipple.com mailto:m...@mattwhipple.com wrote: Is there a presently existing mechanism which flexibly allows for template selection according to the request URI? For instance a request to www.myapp.com/somepage http://www.myapp.com/somepage http://www.myapp.com/somepage would set something like stash(template = 'somepage.tt http://somepage.tt http://somepage.tt') if the file exists and continue to be processed by the appropriate or default action. I wrote something which does this which I'm about to spend some time cleaning up and optimizing but don't want to be reinventing any wheels (especially likely smoother ones). ___ List: Catalyst@lists.scsys.co.uk mailto:Catalyst@lists.scsys.co.uk mailto:Catalyst@lists.scsys.co.uk mailto:Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ Thanks everyone for your input, I'm certainly gathering that there is nothing preexisting that does what I'm looking to do. I'll continue to clean up my version and throw it on CPAN if it seems appealing enough. As a quick overview the basic premise is a more direct link from the path to the template which would be used for those times when the URI path determines presentation after passing through a reusable action handler which tailors content (and doesn't necessarily have to worry about the template selection). This is presently done in the auto action so that overriding the behavior is natural and any extended logic can be handled when and where desired. http://blog.afoolishmanifesto.com ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Loading template according to request path
On Tue, Aug 11, 2009 at 2:15 PM, Matt Whipplem...@mattwhipple.com wrote:
Thanks everyone for your input, I'm certainly gathering that there is
nothing preexisting that does what I'm looking to do. I'll continue to
clean up my version and throw it on CPAN if it seems appealing enough. As a
quick overview the basic premise is a more direct link from the path to the
template which would be used for those times when the URI path determines
presentation after passing through a reusable action handler which tailors
content (and doesn't necessarily have to worry about the template
selection). This is presently done in the auto action so that overriding
the behavior is natural and any extended logic can be handled when and where
desired.
That's precisely what chained actions are for:
sub content : Chained('/') CaptureArgs(0) PathPart('content/as') {
my($self, $c) = @_;
$c-stash-{data} = $c-model('Content');
}
# /content/as/html -- renders root/content/as/html.tt
sub html : Chained('content') Args(0) {}
# /content/as/text -- renders root/content/as/text.tt
sub text : Chained('content') Args(0) {}
# /content/as/graph
# doesn't process a template at all as long as View::SVG sets $c-res-body
sub graph : Chained('content') Args(0) {
my($self, $c) = @_;
$c-forward('View::SVG'); # sets res-body, res-content_type, etc.
}
sub whatever : Chained('content') Args(0) { #etc... }
# insert jshirley's end action here
what's missing?
--
Eden Cardim Need help with your Catalyst or DBIx::Class project?
Code Monkeyhttp://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://edenc.vox.com/http://www.shadowcat.co.uk/servers/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Loading template according to request path
very cool!, live and learn, thanks!!
On Tue, Aug 11, 2009 at 4:59 PM, J. Shirleyjshir...@gmail.com wrote:
On Tue, Aug 11, 2009 at 1:34 PM, Alejandro Imass alejandro.im...@gmail.com
wrote:
Well in Catalyst an action is usually mapped to a controller method,
so I really don't understand your request. Maybe this example will
help:
sub edit : Local {
my ( $self, $c ) = @_;
my $uri = URI-new($c-req-base);
# get whatever you want from the URI
my $auth = $uri-authority;
#do whatever you want with that info...
See perldoc URI
$c-req-uri is a blessed URI object already, so you can just do
$c-req-uri-authority as well.
-J
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Loading template according to request path
Eden Cardim wrote:
On Tue, Aug 11, 2009 at 2:15 PM, Matt Whipplem...@mattwhipple.com wrote:
Thanks everyone for your input, I'm certainly gathering that there is
nothing preexisting that does what I'm looking to do. I'll continue to
clean up my version and throw it on CPAN if it seems appealing enough. As a
quick overview the basic premise is a more direct link from the path to the
template which would be used for those times when the URI path determines
presentation after passing through a reusable action handler which tailors
content (and doesn't necessarily have to worry about the template
selection). This is presently done in the auto action so that overriding
the behavior is natural and any extended logic can be handled when and where
desired.
That's precisely what chained actions are for:
sub content : Chained('/') CaptureArgs(0) PathPart('content/as') {
my($self, $c) = @_;
$c-stash-{data} = $c-model('Content');
}
# /content/as/html -- renders root/content/as/html.tt
sub html : Chained('content') Args(0) {}
# /content/as/text -- renders root/content/as/text.tt
sub text : Chained('content') Args(0) {}
# /content/as/graph
# doesn't process a template at all as long as View::SVG sets $c-res-body
sub graph : Chained('content') Args(0) {
my($self, $c) = @_;
$c-forward('View::SVG'); # sets res-body, res-content_type, etc.
}
sub whatever : Chained('content') Args(0) { #etc... }
# insert jshirley's end action here
what's missing?
I considered using a chain, but figured sticking to my initial idea
offers a more self-contained, flexible solution which potentially frees
the controller actions to focus more on distinct processing and less on
any indistinctly retrieved result destination. Perhaps a more simple
expression of what I'm looking to do is to override the TT View default
of going to a template named according to the action to one named
according to the path (with a little extra DWIMmery). Consider, for
example, an application for which you may want to use customized
templates for certain edge cases in an application. Rather than having
to touch the code at all, the template could be dropped in place in the
right path by a designer and automatically used by the application. For
now I'm going to try it and see if it's useful, counter-productive, or
somewhere in the middle and then either release it for consumption or
bury it and disavow any responsibility for its creation.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Loading template according to request path
On Tue, Aug 11, 2009 at 2:47 PM, Eden Cardim edencar...@gmail.com wrote:
On Tue, Aug 11, 2009 at 2:15 PM, Matt Whipplem...@mattwhipple.com wrote:
Thanks everyone for your input, I'm certainly gathering that there is
nothing preexisting that does what I'm looking to do. I'll continue to
clean up my version and throw it on CPAN if it seems appealing enough.
As a
quick overview the basic premise is a more direct link from the path to
the
template which would be used for those times when the URI path determines
presentation after passing through a reusable action handler which
tailors
content (and doesn't necessarily have to worry about the template
selection). This is presently done in the auto action so that overriding
the behavior is natural and any extended logic can be handled when and
where
desired.
That's precisely what chained actions are for:
sub content : Chained('/') CaptureArgs(0) PathPart('content/as') {
my($self, $c) = @_;
$c-stash-{data} = $c-model('Content');
}
# /content/as/html -- renders root/content/as/html.tt
sub html : Chained('content') Args(0) {}
# /content/as/text -- renders root/content/as/text.tt
sub text : Chained('content') Args(0) {}
# /content/as/graph
# doesn't process a template at all as long as View::SVG sets $c-res-body
sub graph : Chained('content') Args(0) {
my($self, $c) = @_;
$c-forward('View::SVG'); # sets res-body, res-content_type, etc.
}
sub whatever : Chained('content') Args(0) { #etc... }
# insert jshirley's end action here
what's missing?
The fact that Chained doesn't render template from PathPart, but from the
action name? :)
It would be content/html.tt -- not content/as/html.tt
-J
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] XSD Validation of Forms
My comment was perhaps more oriented to using a common declarative validation idiom such as an xml schema because with this particular project, I found myself maintaining FormBuilder YAML files and XSDs. Then I decided to convert HTML to XML and use the common XSD for both. Since most decent XML parsers already perform the validation, and they are usually quite fast, I thought that perhaps something similar to the FormBuilder plug-in could be built that used an XML approach. I like the idea of a single 'base format' which can be used to drive the validation and the form layout too. Is your scheme a format which, when rendered as html, defines the form and, when parsed appropriately, provides the form validation too? As in: form input type=text id=abc format=integer /br / input type=submit / /form - Chris ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
