FAQ
Hello!

Catalyst::Plugin::Prototype is supplied with Prototype 1.4.0; however,
http://prototype.conio.net/ does not work at present and
http://script.aculo.us/ states that current Prototype version is 1.6.1

Can anyont point me at

- interoperability with C::P::P and current Prototype
- maybe other Catalyst JS plugins?

I'm mostly interested in COMPLEX autocompletion right now.

BTW, maybe someone can clue me with my current task

I have a large (10000+) database of people, and many-to-many
relationship people-request, so I should write some form to add people
to request.

Loading all database into selectbox is not suitable for obvious reason.
I'd like to write an Ajax-based autocompletion with "add to list" button
enabled only when selection is fully done.

I'd appreciate any help with solution. I know Perl fairly well but quite
weak with JS

Alex.

Search Discussions

  • Kiffin Gish at Mar 20, 2010 at 2:36 pm
    You might want to have a more detailed look at
    Catalyst::Plugin::AutoCRUD to discover how something similar is being
    done with datagrid lists using Ext Js.
    On Sat, 2010-03-20 at 16:30 +0300, Alex Povolotsky wrote:
    Hello!

    Catalyst::Plugin::Prototype is supplied with Prototype 1.4.0; however,
    http://prototype.conio.net/ does not work at present and
    http://script.aculo.us/ states that current Prototype version is 1.6.1

    Can anyont point me at

    - interoperability with C::P::P and current Prototype
    - maybe other Catalyst JS plugins?

    I'm mostly interested in COMPLEX autocompletion right now.

    BTW, maybe someone can clue me with my current task

    I have a large (10000+) database of people, and many-to-many
    relationship people-request, so I should write some form to add people
    to request.

    Loading all database into selectbox is not suitable for obvious reason.
    I'd like to write an Ajax-based autocompletion with "add to list" button
    enabled only when selection is fully done.

    I'd appreciate any help with solution. I know Perl fairly well but quite
    weak with JS

    Alex.

    _______________________________________________
    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/

    --
    Kiffin Gish <Kiffin.Gish@planet.nl>
    Gouda, The Netherlands
  • Curtis "Ovid" Poe at Mar 20, 2010 at 4:02 pm

    ----- Original Message ----
    From: Kiffin Gish <kiffin.gish@planet.nl>

    You might want to have a more detailed look at
    Catalyst::Plugin::AutoCRUD to
    discover how something similar is being
    done with datagrid lists using Ext
    Js.

    And it looks absolutely lovely and works great but I have three problems with it.

    1. It breaks my app badly.

    It states "If you already have a Catalyst app with DBIx::Class models configured", you only have to add AutoCRUD to the app config. When I go to localhost:3000/autocrud, it works great. When I go to localhost:3000, it breaks with:

    You can connect to your server at http://curtis-poes-computer-3.local:3000
    [warn] Calling $c->view() will return a random view unless you specify one of:
    [warn] * $c->config(default_view => "the name of the default view to use")
    [warn] * $c->stash->{current_view} # the name of the view to use for this request
    [warn] * $c->stash->{current_view_instance} # the instance of the view to use for this request
    [warn] NB: in version 5.81, the "random" behavior will not work at all.
    [error] Caught exception in Veure::View::AutoCRUD::JSON->process "must provide object to convert at /Library/Perl/5.10.1/Catalyst/View/JSON.pm line 44"

    I can't tell why from the docs. This is low priority for me, so I stopped using it as I don't (yet) need this feature.

    2. It also states "No two columns in a given table may have the same FK constraint".

    That breaks a particular use case I have.

    3. It's not clear from the docs (to me) how to restrict access.

    I'm using Catalyst::Controller::ActionRole and a custom role to ensure that certain urls can only be accessed by those with admin privileges. I can't tell how to hook this into AutoCRUD. I suppose I could write a custom subclass of the plugin, so this is the least of my issues.

    Cheers,
    Ovid
  • Denny at Mar 20, 2010 at 4:31 pm

    On Sat, 2010-03-20 at 09:02 -0700, Ovid wrote:
    You can connect to your server at http://curtis-poes-computer-3.local:3000
    [warn] Calling $c->view() will return a random view unless you specify one of:
    [warn] * $c->config(default_view => "the name of the default view to use")
    [warn] * $c->stash->{current_view} # the name of the view to use for this request
    [warn] * $c->stash->{current_view_instance} # the instance of the view to use for this request
    [warn] NB: in version 5.81, the "random" behavior will not work at all.
    [error] Caught exception in Veure::View::AutoCRUD::JSON->process "must provide object to convert at /Library/Perl/5.10.1/Catalyst/View/JSON.pm line 44"

    I can't tell why from the docs.
    Most of that is because your app view is called HTML.pm (at a guess)
    whereas the AutoCRUD one is called TT.pm (iirc). You need to add
    'default_view HTML' to your app's .conf file to stop those warnings.

    Not sure about the exception though, I don't recall having that problem.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 197 bytes
    Desc: This is a digitally signed message part
    Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100320/9ea6b1e7/attachment.pgp
  • Charlie Garrison at Mar 20, 2010 at 4:33 pm
    Good morning,

    On 20/03/10 at 9:02 AM -0700, Ovid
    wrote:
    1. It breaks my app badly.
    You can connect to your server at http://curtis-poes-computer-3.local:3000
    [warn] Calling $c->view() will return a random view unless you specify one of:
    [warn] * $c->config(default_view => "the name of the default view to use")
    [warn] * $c->stash->{current_view} # the name of the view to use for this request
    [warn] * $c->stash->{current_view_instance} # the instance of the view to use for this request
    [warn] NB: in version 5.81, the "random" behavior will not work at all.
    [error] Caught exception in
    Veure::View::AutoCRUD::JSON->process "must provide object to
    convert at /Library/Perl/5.10.1/Catalyst/View/JSON.pm line 44"

    I can't tell why from the docs. This is low priority for me, so I
    stopped using it as I don't (yet) need this feature.
    The fix is given in the warning message, eg:

    __PACKAGE__->config(default_view => 'TT'); # or whatever the
    name of your view is.

    Then you have a 'default' view for your app and Catalyst doesn't
    need to choose one at random. AutoCRUD is adding another view
    and Catalyst doesn't know which one to use by default.

    Assigning a default_view in config is good practice anyway; it's
    not just an issue with AutoCRUD. Add it now, and don't get
    bitten later when the same problem crops up with something else
    (eg. adding a view for sending emails).
    3. It's not clear from the docs (to me) how to restrict access.

    I'm using Catalyst::Controller::ActionRole and a custom role to ensure
    that certain urls can only be accessed by those with admin
    privileges. I can't tell how to hook this into AutoCRUD. I
    suppose I could write a
    custom subclass of the plugin, so this is the least of my issues.
    How about using C::P::Authorization::ACL, eg:

    __PACKAGE__->deny_access_unless(
    "/autocrud",
    [qw/admin/], # user must have role 'admin'
    );

    I balked at adding C::P::Authorization::ACL to my app just for
    AutoCRUD, but I couldn't find a better way of adding auth
    restrictions to AutoCRUD. Maybe someone else will suggest
    something more elegant. (I seem to recall reading something a
    while back about performance degradation with
    C::P::Authorization::ACL; can anyone clarify?)


    Charlie

    --
    ? Charlie Garrison ? <garrison@zeta.org.au>
    ? PO Box 141, Windsor, NSW 2756, Australia

    O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
    http://www.ietf.org/rfc/rfc1855.txt
  • Curtis "Ovid" Poe at Mar 22, 2010 at 10:09 am
    ________________________________
    From: Charlie Garrison <garrison@zeta.org.au>

    The fix is given in the warning message, eg:

    __PACKAGE__->config(default_view => 'TT'); # or whatever the name of your view is.

    Then you have a 'default' view for your app and Catalyst doesn't need to choose one at
    random. AutoCRUD is adding another view and Catalyst doesn't know which one to use by default.

    Many thanks to you and Denny for clearing this up for me.
    I'm using Catalyst::Controller::ActionRole and a custom role to ensure
    that certain urls can only be accessed by those with admin privileges. I can't tell how to hook this into AutoCRUD. I suppose I could write a
    custom subclass of the plugin, so this is the least of my issues.
    How about using C::P::Authorization::ACL, eg:

    __PACKAGE__->deny_access_unless(
    "/autocrud",
    [qw/admin/], # user must have role 'admin'
    );

    Actually, after some discussion with the AutoCRUD author, it was generally agreed it would be safer to not integrate AutoCRUD directly into my app. A different app running on a different domain/subdomain and setting security at the server level seems more appropriate. This is because the author made it clear that authz was not a design concern and the internal URLs vary widely. Rather than risk opening up a hole to the database, separating this is much safer.

    Cheers,
    Ovid
  • Charlie Garrison at Mar 22, 2010 at 11:32 am
    Good evening,

    On 22/03/10 at 3:09 AM -0700, Ovid
    wrote:
    Actually, after some discussion with the AutoCRUD author, it
    was generally agreed it would be safer to not integrate
    AutoCRUD directly into my app. A different app running on a
    different domain/subdomain and setting security at the server
    level seems more appropriate. This is because the author made
    it clear that authz was not a design concern and the internal
    URLs vary widely. Rather than risk opening up a hole to the
    database, separating this is much safer.
    I'd really like to get more info on that. Looking at all the
    actions for my app in the debug output on startup, I can see
    lots of private and chained actions for AutoCRUD, and they are
    all under the /autocrud path. What part of AutoCRUD is accessed
    outside the /autocrud path?

    AutoCRUD is very nice convenience, but it's not so nice to
    warrant running a separate app for it. To me, *having* to run a
    separate app indicates a design flaw. And if that's the case
    then I need to look at alternate solutions. (Note, I'm not
    against server-level auth, and I use it for other things outside
    my app, but within the app.....)

    Is the author on this list? Can you provide any further insight
    into why authz for the /autocrud path is not sufficient? I'm
    somewhat baffled that a tool which effectively allows full
    access to the DBIC model doesn't at least consider authz as part
    of the design.

    Sorry, there's lots of red flags waving around and I'm not sure
    whether I should pay attention to them.

    Thanks,
    Charlie

    --
    ? Charlie Garrison ? <garrison@zeta.org.au>
    ? PO Box 141, Windsor, NSW 2756, Australia

    O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
    http://www.ietf.org/rfc/rfc1855.txt
  • Curtis "Ovid" Poe at Mar 22, 2010 at 11:41 am

    ----- Original Message ----
    From: Charlie Garrison <garrison@zeta.org.au>
    I'd really like to get more info on that.
    Looking at all the actions for my app in the debug output on startup, I can see
    lots of private and chained actions for AutoCRUD, and they are all under the
    /autocrud path. What part of AutoCRUD is accessed outside the /autocrud
    path?
    AutoCRUD is very nice convenience, but it's not so nice to warrant
    running a separate app for it. To me, *having* to run a separate app indicates a
    design flaw. And if that's the case then I need to look at alternate solutions.
    (Note, I'm not against server-level auth, and I use it for other things outside
    my app, but within the app.....)

    I can't answer these questions. I can only refer you to the rt queue discussion:

    https://rt.cpan.org/Ticket/Display.html?idU742

    I didn't see creating a separate app and securing it at the server level as being a big deal (for me, your mileage may vary). It seemed easy enough that I wasn't terribly inclined to look further at potential security holes by integrating AutoCRUD directly (I'm very concerned about security for this app and if I see an easy route to better security, I'm going to take it). If you want "all or nothing" AutoCRUD, this may not be an issue. If you desperately need fine-grained control, it could be complicated. Again, see the RT discussion.

    Cheers,
    Ovid
  • Charlie Garrison at Mar 22, 2010 at 12:32 pm
    Good evening,

    On 22/03/10 at 4:41 AM -0700, Ovid
    wrote:
    I can't answer these questions. I can only refer you to the rt queue discussion:

    https://rt.cpan.org/Ticket/Display.html?idU742
    Thanks, that answered some things, but also just made others
    even more confusing.

    Your comment:
    This is because the author made it clear that authz was not a design
    concern and the internal URLs vary widely. Rather than risk opening up
    a hole to the database, separating this is much safer.
    But the author says in the RT ticket:
    Having said that, you should be able to match on the AutoCRUD paths
    within your custom ACL role because they are quite predictable:

    /autocrud/* - obviously just your admins
    /autocrud/<db-name>/<table> will be the page for any table
    So, while the URLs may vary widely, they are "quite predictable".

    Maybe this discussion went off track about being able to specify
    different authz for different portions of AutoCRUD. I'm happy
    with a simple 'any admin can access the whole db' approach. In
    which case the ACL for /autocrud should be sufficient. Or am I
    missing something?

    In that ticket the AutoCRUD author also states:
    This has more to do with the philosophy of AutoCRUD. It's meant as a
    tool for the application developer more than the end user, so I have
    never focused on authZ.
    And that sort of makes sense, but who is the end-user? Is it my
    $customer, or is it their users of the site? For me, the
    end-user is my $customer and I want to give them full access to
    the database. And AutoCRUD seems like a simple way to achieve
    that. For the app developer, AutoCRUD seems like a toy; I need
    much better/direct db access than is available via AutoCRUD.

    So, for the developer, AutoCRUD is a weak tool, and for the
    end-user there is no 'proper' support for authz. There seems to
    be a big gap. Anyway, for now I'm going with the comment
    "AutoCRUD paths ... are quite predictable", and rely on the ACL
    plugin to give the desired authz.
    I didn't see creating a separate app and securing it at the
    server level as being a big deal (for me, your mileage may vary).
    Between the different devs (& even some developers), the test
    server, production server, etc. it's not trivial to simply "add
    another app". Of course it's doable, but I'd prefer to spend my
    efforts on app development than helping designers
    install/configure a second app.

    So, thanks for bringing up this issue. It has made me aware of
    some limitations that I hadn't looked at before.

    And if anyone thinks that using the Auth::ACL plugin for
    protecting direct db access (eg. /autocrud) is a bad idea,
    please share your thoughts.

    Thanks,
    Charlie

    --
    ? Charlie Garrison ? <garrison@zeta.org.au>
    ? PO Box 141, Windsor, NSW 2756, Australia

    O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
    http://www.ietf.org/rfc/rfc1855.txt
  • Oliver Gorwits at Mar 22, 2010 at 12:28 pm
    Hi Charlie,

    I'm the author of AutoCRUD, and fully support the route Ovid has
    taken, indeed it's how we use AutoCRUD at my workplace: under its
    own Apache <Location> with specific Apache ACLs for admin staff.
    On 22/03/2010 11:32, Charlie Garrison wrote:
    What part of AutoCRUD is accessed outside the /autocrud path?
    You might be misunderstanding how AutoCRUD works. The "/autocrud"
    base is just a default - you can set this to something else or even
    "". That means I cannot tell you what paths to protect, you need to
    work it out for yourself, although they will be self-contained.

    If you want to control access on a per-table basis, then your ACLs
    are based on path parts which are constructed on the fly from your
    DB schema and table names, and there is a risk you will get it
    wrong. It's not even easy for me to document, because schema and
    table names are not transposed literally into the path.
    To me, *having* to run a separate app
    indicates a design flaw. And if that's the case then I need to look at
    alternate solutions.

    I'm somewhat baffled
    that a tool which effectively allows full access to the DBIC model
    doesn't at least consider authz as part of the design.
    I think you're a little wide of the mark here. There are many CRUD
    solutions for Catalyst/DBIC, each with strengths and weaknesses. As
    t0m put it very well in another thread:

    "AutoCRUD is very simple and easy to use, works like a charm and
    also gives you absolutely no configurability."

    If you want tight control over how your CRUD works then build the
    CRUD yourself using one of the other frameworks[1]. Please don't
    criticize AutoCRUD for not addressing a given feature - there are
    any number of use cases where the plugin is perfectly adequate.

    regards,
    oliver.

    [1] e.g. CatalystX::CRUD, CatalystX::CRUD::YUI or Catalyst::Manual
    - --
    Oliver Gorwits, Network and Telecommunications Group,
    Oxford University Computing Services
  • Charlie Garrison at Mar 22, 2010 at 1:08 pm
    Good morning,

    Thanks for the reply, and that means much of my previous message
    can be ignored.

    On 22/03/10 at 12:28 PM -0000, Oliver Gorwits
    wrote:
    On 22/03/2010 11:32, Charlie Garrison wrote:
    What part of AutoCRUD is accessed outside the /autocrud path?
    You might be misunderstanding how AutoCRUD works. The "/autocrud"
    base is just a default - you can set this to something else or even
    "". That means I cannot tell you what paths to protect, you need to
    work it out for yourself, although they will be self-contained.
    The "self-contained" part is what I really wanted to know. I'm
    aware the base can change to something else; I'm fine with that.
    If you want to control access on a per-table basis, then your ACLs
    are based on path parts which are constructed on the fly from your
    DB schema and table names, and there is a risk you will get it
    wrong. It's not even easy for me to document, because schema and
    table names are not transposed literally into the path.
    Thanks, but I'm just looking for a shotgun (all or nothing) approach.
    I think you're a little wide of the mark here. There are many CRUD
    solutions for Catalyst/DBIC, each with strengths and weaknesses. As
    t0m put it very well in another thread:

    "AutoCRUD is very simple and easy to use, works like a charm and
    also gives you absolutely no configurability."
    The easy to use part is why I chose it. I wanted something easy
    for my customers to use, and easy for me to implement. And
    AutoCRUD meets those criteria *very* well.
    If you want tight control over how your CRUD works then build the
    CRUD yourself using one of the other frameworks[1]. Please don't
    criticize AutoCRUD for not addressing a given feature - there are
    any number of use cases where the plugin is perfectly adequate.
    Sorry, it was not meant as a criticism. Apologies if it came
    across that way. It was my confusion on what the target audience
    for it is. I honestly don't see the benefit as a 'developers
    tool'. That is only my opinion. I do see great benefit for
    end-users though. I can see lots of work has gone into AutoCRUD
    it's great for what it does.

    So, apologies if I wasn't clear; it's really been "one of those
    days". I like AutoCRUD; I just want to make sure I'm using it
    the right way. And there seemed to be conflicting information
    which just confused me.

    Thanks again for your reply, hopefully I've cleared up why I
    made my comments.

    Charlie

    --
    ? Charlie Garrison ? <garrison@zeta.org.au>
    ? PO Box 141, Windsor, NSW 2756, Australia

    O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
    http://www.ietf.org/rfc/rfc1855.txt
  • Oliver Gorwits at Mar 22, 2010 at 10:39 pm
    Hi Charlie,
    On 22/03/2010 13:08, Charlie Garrison wrote:
    The "self-contained" part is what I really wanted to know. I'm
    aware the base can change to something else; I'm fine with that.

    I'm just looking for a shotgun (all or nothing) approach.
    In which case yes, I would leave the default path base of
    "/autocrud" (or set it to something else), and then place a single
    ACL on that - all AutoCRUD operations will be protected.

    regards,
    oliver.
    - --
    Oliver Gorwits, Network and Telecommunications Group,
    Oxford University Computing Services
  • Dami Laurent (PJ) at Mar 21, 2010 at 6:30 pm

    -----Message d'origine-----
    De : Alex Povolotsky
    Envoy? : samedi, 20. mars 2010 14:30
    Can anyont point me at

    - interoperability with C::P::P and current Prototype
    - maybe other Catalyst JS plugins?

    I'm mostly interested in COMPLEX autocompletion right now.

    BTW, maybe someone can clue me with my current task

    I have a large (10000+) database of people, and many-to-many
    relationship people-request, so I should write some form to add people
    to request.

    Loading all database into selectbox is not suitable for
    obvious reason.
    I'd like to write an Ajax-based autocompletion with "add to
    list" button
    enabled only when selection is fully done.
    Hi Alex,

    If you need sophisticated autocompletion, have a look at
    http://cpansearch.perl.org/src/DAMI/Alien-GvaScript-1.21/doc/html/Intro.html
    http://cpansearch.perl.org/src/DAMI/Alien-GvaScript-1.21/doc/html/AutoCompleter.html


    There is no Catalyst plugin but it's quite simple to integrate it into a Catalyst app :

    a) write a Controller that will receive the Ajax requests and answer with a JSON datastructure (arrayref of possible values, or, if you want more complex behaviour on the client-side, arrayref of hashrefs with several fields for each returned entry).
    b) serve the GvaScript.js file through Static::Simple or directly through your HTTP server
    c) in your HTML page, include the GvaScript.js and write the JS code for initialising the Autocompleter object, giving it the URL for the Ajax controller and setting the appropriate options, as described in the doc. You can specify delays, case sensitivity, strictness, typeahead features, dependent fields, and many other options.

    If you need an example, install the Pod::POM::Web local documentation server and see how it works; it uses the autocompleter for perl functions and perl variables.

    Good luck, Laurent Dami

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedMar 20, '10 at 1:30p
activeMar 22, '10 at 10:39p
posts13
users7
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase