Re: [Catalyst] Alternatives to Catalyst ?

[Ben van Staveren]

If using  ->params->{name} (i.e. the direct hash approach) is like
juggling grenades - then what is like using the ->param( 'name' ) way
of doing it?
  
Actually ->params->{name} is the juggling teddybears one (the "proper" 
way to do it). If you do $c->{request}->{params}->{name} - that's the 
grenade way.


-.param('name') is juggling sharp knives :)


I am asking this because your grenades analogy gives the impression
that you you are against doing direct hash access for every price -
but I think the general advice is that in this particular case using
the ->param( 'name' ) is worse than using the direct hash access.
  
Sorry if I wasn't quite clear on it, in the specific case of 
$c->req->params and consorts, doing $c->req->params->{ ... } is the 
"right" way to do it, after all, params returns a hashref and offers no 
further encapsulation; using ->req->param('foo') would work, but is just 
a compatibility shim for CGI and comes with some major drawbacks.


I was, however, speaking in general; it's often better to be able to do 
$object->get_foo/$object->set_foot (or $object->foo which does both), 
than to go $object->{foo} = ...;


In some cases, it's not, sometimes you need to get rid of the overhead, 
but the common "idea" at that point is that IF you need to break 
encapsulation, comment it right, and indicate WHY you're doing it.





  


--
Ben van Staveren
phone: +62 81 70777529
email: benvanstave...@gmail.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] Alternatives to Catalyst ?

[Ben van Staveren]

Hi Paul,

Don't get me wrong, but my opinion is pretty much opposite from yours, 
if people come and ask a good question (which Dermot did), and seem to 
be -not- total noobs, then they get a free CompSci lesson to go with the 
answer they've gotten :)


Maybe that's just me, but I always like knowing -why- a certain answer 
was given - besides just the "this is how it should be" kind of answer :)


Anyways, he got both the answer he was looking for, and some tips from 
people - perhaps some of us feel more strongly about it than others, but 
hey, that's what makes things interesting no?


Paul Makepeace wrote:

Even if you're not, direct hash accessing is basically akin to juggling
grenades. It might go right for a long time, but eventually the pin's going
to come out and there will be a very messy BLAM.

Even if it is code you just write for yourself, still doesn't hurt to make
sure you avoid the BLAM bit :)



(Replying in general, to the sense of this email which others have related too)

Dermot, to my reading at least, has been clear twice now that he was
asking specifically about how to retrieve parameters -- presumably not
coming to a web framework list for an unsolicited computer science
lecture on encapsulation...

I think it behooves us as a community to afford posters when they
clearly articulate a question and context, as Dermot has*, not to
treat them as complete noobs. It'd be a shame if folks became
reluctant to ask 'simple' questions for fear of half a dozen catalyst
old-skoolers delivering a sermon.

(Even these questions often reveal useful tidbits like the CGI compat hazard.)

Paul

* not the OP!

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

  


--
Ben van Staveren
phone: +62 81 70777529
email: benvanstave...@gmail.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] Suggestions for iPhone version of app

[Chris]

On Tue, Apr 27, 2010 at 12:22 AM, Steve Nolte  wrote:
> We have a Catalyst app that we are looking to also make available through an 
> iPhone interface.

I had good results with iUI to get iPhone native look-and-feel in a
Catalyst web app. It's fairly basic, but I only needed basic..

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

[Catalyst] Re: Alternatives to Catalyst ?

[Aristotle Pagaltzis]

* Zbigniew Lukasiak  [2010-04-26 12:25]:
> This is a fine advice - but unfortunately the ->param method
> call suffers from additional problem - which is described in
> much detail in the documentation (go to the NOTE at:
> http://search.cpan.org/~bobtfish/Catalyst-Runtime-5.80022/lib/Catalyst/Request.pm#$req-%3Eparam).

Yeah, but the ->params hash has the converse problem: if you
write

$c->model->insert_person( name => $c->req->params->{'name'} )

then you may be surprised to find out there are people with name
like ARRAY(0xDEADBEEF). Of course that’s just a relatively minor
case of data corruption. Worse is if you legitimately expect
a parameter to have one or more values, eg. a pile of checkboxes.
Then you have to constantly check whether you’re getting a scalar
or an array reference.

So either you use the legacy method and have to protect against
getting more values than you wanted, or you use the suggested
method and have to protect against getting fewer values than you
expect in the general case.

I briefly tried to write something to stick Hash::MultiValue into
Catalyst to end the madness, but doing it properly would require
a plugin, plus HTTP::BodyParser (I think) was using a misdesigned
approach that made deep integration of H::MV impossible (with
properly preserved k/v pair order).

Could have written a Request role… but that seemed unsatisfying.

I wonder whether it would be possible to rip out the respective
bits from Cat and use just H::MV, and leave the current stuff to
a compat plugin or something like that…

Regards,
-- 
Aristotle Pagaltzis // 

___
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] Alternatives to Catalyst ?

[Stuart Watt]

Part of the point, surely, is that we don't (want to) know what is 
inside $c/$c->request (or any other Catalyst structure). The "direct 
hash" could easily be a tied something-or-other inside, as is the case 
with CGI when you use the Vars accessor. So just because it looks like a 
direct hash, you can't from the outside assume it is more efficient. In 
CGI, for example, the tied hash accessors (if you use Vars) are defined 
in terms of the param method, so this mechanism is actually less 
efficient than using param calls directly.


The point is: we can't/I wouldn't make assumptions about efficiency 
based on the appearance of code, at least not in a language like Perl 
where there can be so much magic behind the calling conventions.


If there is a recommended way of doing this, I'd certainly want to know 
it. And it would probably help if that was efficient, but so long as it 
doesn't leak or expose internal hackery, it shouldn't really matter. And 
if it does, then it should probably be deprecated or documented so we 
can avoid problems.


Perhaps it would have been better if the internal hash keys had been the 
usual private-style "_parameters", etc., as that way everyone would know 
direct access as a no-no, because the accessors would work but not the 
direct access.


--S
--
Stuart Watt
ARM Product Developer
Information Balance

___
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] Alternatives to Catalyst ?

[J. Shirley]

On Mon, Apr 26, 2010 at 1:51 PM, Zbigniew Lukasiak  wrote:
> On Mon, Apr 26, 2010 at 1:26 PM, Ben van Staveren
>  wrote:
>>
>> Because if you are working with, say, 10 people on a team, and you will have
>> everyone merrily doing direct hash accesses, sooner or later, someone's
>> going to fuck it up and something will break in a spectacular > fashion.
>>
>>
>> I take your point even though I am not in a team.
>>
>>
>>
>> Even if you're not, direct hash accessing is basically akin to juggling
>> grenades. It might go right for a long time, but eventually the pin's going
>> to come out and there will be a very messy BLAM.
>>
>> Even if it is code you just write for yourself, still doesn't hurt to make
>> sure you avoid the BLAM bit :)
>
> If using  ->params->{name} (i.e. the direct hash approach) is like
> juggling grenades - then what is like using the ->param( 'name' ) way
> of doing it?
> I am asking this because your grenades analogy gives the impression
> that you you are against doing direct hash access for every price -
> but I think the general advice is that in this particular case using
> the ->param( 'name' ) is worse than using the direct hash access.
>
>

I believe the discussion is about $c->req->{parameters}->{name}, not
about using ->params->{name}, isn't it?

Analogies to grenades, gas pumps and whatever else are just silly.  We
all understand software development sufficiently well enough to simply
talk at the matter at hand.

Violating encapsulation in a local, protected scope for purposes of
efficiency is ok.
Violating encapsulation on a global scope is not, for a variety of
reasons, the most obvious of which is you have no contract for data
access.

I don't believe that $c->req->params violates any ideas, since the
parameters is nothing more than a hashref.  How you get that hashref,
though, is a binding contract to the request.  Calling
$c->req->{params} is an evil, naughty thing.

-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] Alternatives to Catalyst ?

[Zbigniew Lukasiak]

On Mon, Apr 26, 2010 at 1:26 PM, Ben van Staveren
 wrote:
>
> Because if you are working with, say, 10 people on a team, and you will have
> everyone merrily doing direct hash accesses, sooner or later, someone's
> going to fuck it up and something will break in a spectacular > fashion.
>
>
> I take your point even though I am not in a team.
>
>
>
> Even if you're not, direct hash accessing is basically akin to juggling
> grenades. It might go right for a long time, but eventually the pin's going
> to come out and there will be a very messy BLAM.
>
> Even if it is code you just write for yourself, still doesn't hurt to make
> sure you avoid the BLAM bit :)

If using  ->params->{name} (i.e. the direct hash approach) is like
juggling grenades - then what is like using the ->param( 'name' ) way
of doing it?
I am asking this because your grenades analogy gives the impression
that you you are against doing direct hash access for every price -
but I think the general advice is that in this particular case using
the ->param( 'name' ) is worse than using the direct hash access.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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] Alternatives to Catalyst ?

[Lyle]

Paul Makepeace wrote:

Except that he gave context & obvious (to me at least) understanding.

I agree in some situations it's clear the poster is asking something
where they need some steering and/or "XY Problem" but my call is that
we give posters some credit, esp where it's clearly due.
  


Have to agree with Paul here. Keeping the newbies happy is vital for 
growth and popularity, and unfortunately something too many Perl groups 
overlook.



Lyle



___
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] Alternatives to Catalyst ?

[Paul Makepeace]

On Mon, Apr 26, 2010 at 12:48, Wade Stuart  wrote:
> (Replying in general, to the sense of this email which others have related
> too)
>>
>> Dermot, to my reading at least, has been clear twice now that he was
>> asking specifically about how to retrieve parameters -- presumably not
>> coming to a web framework list for an unsolicited computer science
>> lecture on encapsulation...
>>
>> I think it behooves us as a community to afford posters when they
>> clearly articulate a question and context, as Dermot has*, not to
>> treat them as complete noobs. It'd be a shame if folks became
>> reluctant to ask 'simple' questions for fear of half a dozen catalyst
>> old-skoolers delivering a sermon.
>>
>
> Sorry,  it is akin to someone driving up to you while you are in a gas
> station in a unleaded ford asking very nicely "Do you know where the diesel
> pumps are"?

Except that it isn't:

"Obviously I'd rather use the faster method but if I'm breaking the
encapsulation in some ways that's going to bite me later, I'd steer
clear."

I don't know how much more of an articulate disclaimer you need.

>  The question is literate and well formed but in context implies
> lack of understanding.

Except that he gave context & obvious (to me at least) understanding.

I agree in some situations it's clear the poster is asking something
where they need some steering and/or "XY Problem" but my call is that
we give posters some credit, esp where it's clearly due.

Paul

___
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] Pre-Moose version of Catalyst and all plugins?

[Kee Hinckley]

I'm trying to get some old code running in a hurry. Unfortunately Moose has 
completely fouled things up.First it broke my use of Error.pm (conflict with 
"with"). Fortunately I didn't use "with", and could just comment it out. But 
what I did have was my own Error subclass that was the Catalyst Exception class.

BEGIN {
$Catalyst::Exception::CATALYST_EXCEPTION_CLASS = 'Error::Throws';
};

I have no idea how to even get started on making that work. I made Error a 
Moose inherited module from Catalyst::Exception (which is the wrong level, but 
it got rid of:

Not inlining 'new' for Catalyst::Exception since it is not inheriting the 
default Moose::Object::new
If you are certain you don't need to inline your constructor, specify 
inline_constructor => 0 in your call to 
Catalyst::Exception->meta->make_immutable

But then that left me with

Recursive inheritance detected while looking for method 'isa' in package 
'Catalyst::Exception' at /usr/local/lib/perl/5.8.8/Class/MOP/Class.pm line 570.

If someone has a quick way of telling me how to make my code compatible with 
Catalyst::Exception that would be great, but I'm worried that I'm going to hit 
lots of other things like this. In particular, I'm also using Embperl as a 
Catalyst interpreter instead of TT, so I may hit Moose again there. It might be 
easier for me to just take a step back in time and get old versoins:

use Catalyst (qw{
-Debug 
-Home=root/src
ConfigLoader
Static::Simple

StackTrace

Authentication
Authentication::Store::DBIC
Authentication::Credential::Password

Authorization::Roles
Authorization::ACL

Session
Session::Store::DBIC
Session::State::Cookie
Cache

Prototype
Params::Nested
SubRequest

ThrowForward});

Any suggestion on a solution that isn't going to take me days?


Kee Hinckley
Owner, Somewhere LLC.   Somewhere: http://www.somewhere.com/TechnoSocial: 
http://xrl.us/bh35i

___
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] Alternatives to Catalyst ?

[kevin montuori]

On Mon, Apr 26, 2010 at 3:48 PM, Wade Stuart  wrote:

> Sorry,  it is akin to someone driving up to you while you are in a gas
> station in a unleaded ford asking very nicely "Do you know where the diesel
> pumps are"?  The question is literate and well formed but in context implies
> lack of understanding.

Not if there's a spare can in the trunk for the backhoe.  Everybody's
situation is different, and there's often a good reason for seemingly
"incorrect" questions.

k.

-- 
kevin montuori

___
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] Alternatives to Catalyst ?

[Wade Stuart]

(Replying in general, to the sense of this email which others have related
too)

>
> Dermot, to my reading at least, has been clear twice now that he was
> asking specifically about how to retrieve parameters -- presumably not
> coming to a web framework list for an unsolicited computer science
> lecture on encapsulation...
>
> I think it behooves us as a community to afford posters when they
> clearly articulate a question and context, as Dermot has*, not to
> treat them as complete noobs. It'd be a shame if folks became
> reluctant to ask 'simple' questions for fear of half a dozen catalyst
> old-skoolers delivering a sermon.
>
>
Sorry,  it is akin to someone driving up to you while you are in a gas
station in a unleaded ford asking very nicely "Do you know where the diesel
pumps are"?  The question is literate and well formed but in context implies
lack of understanding.  I would choose to answer,  "You know, are not
driving a diesel and putting unleaded in that car will break it -- the pumps
are over there".  If you want unadulterated bits in response to questions go
read the source,  if you ask here there are many people that actually read
the questions and respond with holistic information that may not be the
exact output you are looking for.

Second and more important,  the responses are offered for free -- complaints
are considered a cost.

Kindest,
-Wade
___
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] Alternatives to Catalyst ?

[Paul Makepeace]

> Even if you're not, direct hash accessing is basically akin to juggling
> grenades. It might go right for a long time, but eventually the pin's going
> to come out and there will be a very messy BLAM.
>
> Even if it is code you just write for yourself, still doesn't hurt to make
> sure you avoid the BLAM bit :)

(Replying in general, to the sense of this email which others have related too)

Dermot, to my reading at least, has been clear twice now that he was
asking specifically about how to retrieve parameters -- presumably not
coming to a web framework list for an unsolicited computer science
lecture on encapsulation...

I think it behooves us as a community to afford posters when they
clearly articulate a question and context, as Dermot has*, not to
treat them as complete noobs. It'd be a shame if folks became
reluctant to ask 'simple' questions for fear of half a dozen catalyst
old-skoolers delivering a sermon.

(Even these questions often reveal useful tidbits like the CGI compat hazard.)

Paul

* not the OP!

___
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] Using Jquery UI Autocomplete widget with Catalyst::View::JSON

[Alexander Hartmaier]

HRI will return prefetched rels too, get_columns won't.

--
Best regards, Alex


Am Montag, den 26.04.2010, 17:23 +0200 schrieb Ben van Staveren:
> Used it but at the same time, doing my $hashref =
> { $row->get_columns } got me more or less the same effect for a lot
> less hassle :)
>
> I actually do this for most my DB objects that get serialised to JSON,
> quite simple case of $c->stash->{json} = [ map { $_->get_columns }
> $rs->all ];
>
> In a similar vein, I haven't yet really seen/heard any sort of "best
> practices" when it comes to Catalyst and JSON, so maybe I'm going
> about it all wrong but eh :)
>
> Lee Aylward wrote:
> > On Mon, 26 Apr 2010 16:33:31 +0700
> > Ben van Staveren  wrote:
> >
> >
> > > Probably not the most pretty one but:
> > >
> > > Given you have a resultset obtained with, say,
> > >
> > > my $result_set = $c->model('DB::Somedata')->search_rs({...}, {...});
> > >
> > > $c->stash->{json} = [
> > >   map { id => $_->id, label => $_->name } ($result_set->all)
> > >   ];
> > >
> > > Or a bit more verbose:
> > >
> > > foreach my $result ($result_set->all) {
> > >   push(@{$c->stash->{json}}, { id => $result->id, label =>
> > > $result->name }); }
> > >
> > >`
> > >
> > >
> >
> > I've also had good luck using DBIx::Class::RsultClass::HashRefInflator
> > in the past. It doesn't give you quite as much control, but it may be
> > enough for your needs.
> >
> > http://search.cpan.org/~frew/DBIx-Class/lib/DBIx/Class/ResultClass/HashRefInflator.pm
> >
> >
>
> --
> Ben van Staveren
> phone: +62 81 70777529
> email: benvanstave...@gmail.com


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH   Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*

___
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] Using Jquery UI Autocomplete widget with Catalyst::View::JSON

[Ben van Staveren]

Used it but at the same time, doing my $hashref = { $row->get_columns } 
got me more or less the same effect for a lot less hassle :)


I actually do this for most my DB objects that get serialised to JSON, 
quite simple case of $c->stash->{json} = [ map { $_->get_columns } 
$rs->all ];


In a similar vein, I haven't yet really seen/heard any sort of "best 
practices" when it comes to Catalyst and JSON, so maybe I'm going about 
it all wrong but eh :)


Lee Aylward wrote:

On Mon, 26 Apr 2010 16:33:31 +0700
Ben van Staveren  wrote:

  

Probably not the most pretty one but:

Given you have a resultset obtained with, say,

my $result_set = $c->model('DB::Somedata')->search_rs({...}, {...});

$c->stash->{json} = [
  map { id => $_->id, label => $_->name } ($result_set->all)
  ];

Or a bit more verbose:

foreach my $result ($result_set->all) {
  push(@{$c->stash->{json}}, { id => $result->id, label =>
$result->name }); }

   `




I've also had good luck using DBIx::Class::RsultClass::HashRefInflator
in the past. It doesn't give you quite as much control, but it may be
enough for your needs.

http://search.cpan.org/~frew/DBIx-Class/lib/DBIx/Class/ResultClass/HashRefInflator.pm

  


--
Ben van Staveren
phone: +62 81 70777529
email: benvanstave...@gmail.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] Suggestions for iPhone version of app

[Steve Nolte]

> HTTP::BrowserDetect gives you the detection, and you could setup a
> separate view for those templates with a fallback to the previous
> templates.
> 
> You configure the secondary view with multiple paths (INCLUDE_PATH),
> so you can override any template (just by it existing in the first
> dir).

Nice, I like this route.  It looks like I can just put that detection logic in 
the default end() action, pretty simple.

> On a separate, and more involved note, SproutCore Touch has just been
> released.

Thanks for this suggestion, I didn't know SproutCore has a Touch interface.

___
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] Using Jquery UI Autocomplete widget with Catalyst::View::JSON

[Lee Aylward]

On Mon, 26 Apr 2010 16:33:31 +0700
Ben van Staveren  wrote:

> Probably not the most pretty one but:
> 
> Given you have a resultset obtained with, say,
> 
> my $result_set = $c->model('DB::Somedata')->search_rs({...}, {...});
> 
> $c->stash->{json} = [
>   map { id => $_->id, label => $_->name } ($result_set->all)
>   ];
> 
> Or a bit more verbose:
> 
> foreach my $result ($result_set->all) {
>   push(@{$c->stash->{json}}, { id => $result->id, label =>
> $result->name }); }
> 
>`
> 

I've also had good luck using DBIx::Class::RsultClass::HashRefInflator
in the past. It doesn't give you quite as much control, but it may be
enough for your needs.

http://search.cpan.org/~frew/DBIx-Class/lib/DBIx/Class/ResultClass/HashRefInflator.pm

-- 
Lee Aylward

___
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] Suggestions for iPhone version of app

[J. Shirley]

On Mon, Apr 26, 2010 at 7:47 AM, Steve Nolte  wrote:
>> On 4/26/2010 10:22 AM, Steve Nolte wrote:
>> > And any frameworks, such as jQTouch, to recommend or stay away from?
>>
>> I've heard good things about http://www.phonegap.com/
>
> Thanks for the PhoneGap suggestions, but to clarify I'm looking for something 
> to first help me build the iPhone version of my web app.  PhoneGap is for 
> bundling up a web app you have as an actual iPhone App.
>
> So my request for framework suggestions is more specifically for something 
> that will help me create the UI.  And I'm wondering if anyone else has gone 
> through the work to build a Catalyst app with both a desktop and mobile 
> interface.


HTTP::BrowserDetect gives you the detection, and you could setup a
separate view for those templates with a fallback to the previous
templates.

You configure the secondary view with multiple paths (INCLUDE_PATH),
so you can override any template (just by it existing in the first
dir).

On a separate, and more involved note, SproutCore Touch has just been released.

You can read about it in the introduction article on the sproutcore blog here:
http://blog.sproutcore.com/post/531215199/introducing-sproutcore-touch

Unfortunately it looks like touch.sproutcore.com is having its own issues.

To give you an idea of how it works, you'll actually be building a
full client-side application that communicates with your application,
in terms of data storage, etc.

This will give you the most native feeling, seemingly just like that
of a real application.  It also handles local storage, so you can
cache things directly on the device itself.

Hope this helps, have fun.

-Jay

___
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] Suggestions for iPhone version of app

[Steve Nolte]

> On 4/26/2010 10:22 AM, Steve Nolte wrote:
> > And any frameworks, such as jQTouch, to recommend or stay away from?
> 
> I've heard good things about http://www.phonegap.com/

Thanks for the PhoneGap suggestions, but to clarify I'm looking for something 
to first help me build the iPhone version of my web app.  PhoneGap is for 
bundling up a web app you have as an actual iPhone App.

So my request for framework suggestions is more specifically for something that 
will help me create the UI.  And I'm wondering if anyone else has gone through 
the work to build a Catalyst app with both a desktop and mobile interface.

___
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] Suggestions for iPhone version of app

[Jacob Helwig]

On Mon, Apr 26, 2010 at 07:40, Peter Edwards  wrote:
>
> On 26 April 2010 15:35, Jim Spath  wrote:
>>
>> On 4/26/2010 10:22 AM, Steve Nolte wrote:
>>>
>>> And any frameworks, such as jQTouch, to recommend or stay away from?
>>
>> I've heard good things about http://www.phonegap.com/
>
> Watch out for Apple's restrictive policy
> http://blogs.zdnet.com/Burnette/?p=1904
> Regards, Peter

Fortunately, these policies have nothing to do with web-apps geared
towards the iPhone (from what I've seen).

___
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] Suggestions for iPhone version of app

[Peter Edwards]

On 26 April 2010 15:35, Jim Spath  wrote:

> On 4/26/2010 10:22 AM, Steve Nolte wrote:
>
>> And any frameworks, such as jQTouch, to recommend or stay away from?
>>
>
> I've heard good things about http://www.phonegap.com/
>
>
Watch out for Apple's restrictive policy

http://blogs.zdnet.com/Burnette/?p=1904

Regards, Peter
___
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] Suggestions for iPhone version of app

[Jim Spath]

On 4/26/2010 10:22 AM, Steve Nolte wrote:

And any frameworks, such as jQTouch, to recommend or stay away from?


I've heard good things about http://www.phonegap.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/

[Catalyst] Suggestions for iPhone version of app

[Steve Nolte]

We have a Catalyst app that we are looking to also make available through an 
iPhone interface.  Does anyone have any suggestions or experiences to share on 
how to implement this?  For example, since we're using TT, would a duplicate 
set of templates that are updated for a mobile version be smart?  And any 
frameworks, such as jQTouch, to recommend or stay away from?

Thanks,
Steve

___
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] Alternatives to Catalyst ?

[Ben van Staveren]

Because if you are working with, say, 10 people on a team, and you will have 
everyone merrily doing direct hash accesses, sooner or later, someone's going to 
fuck it up and something will break in a spectacular > fashion.



I take your point even though I am not in a team.

  
Even if you're not, direct hash accessing is basically akin to juggling 
grenades. It might go right for a long time, but eventually the pin's 
going to come out and there will be a very messy BLAM.


Even if it is code you just write for yourself, still doesn't hurt to 
make sure you avoid the BLAM bit :)


--
Ben van Staveren
phone: +62 81 70777529
email: benvanstave...@gmail.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] Alternatives to Catalyst ?

[Dermot]

On 26 April 2010 12:02, Ovid  wrote:
> - Original Message 
>> From: Dermot 
>
>
>> Why wouldn't you, as you write, use the the fastest access methods
>> available? Surely you'd want to develop habits that will a) provide
>> better performance and b) as mentioned below avoid the thorny
>> side-effects of req->params().  This isn't a matter of premature
>> optimisation but simply establishing good practise.

> Because if you are working with, say, 10 people on a team, and you will have 
> everyone merrily doing direct hash accesses, sooner or later, someone's going 
> to fuck it up and something will break in a spectacular > fashion.

I take your point even though I am not in a team.

> This is a very common trap that many developers (even experienced ones) get 
> caught up in.  Let's make *everything* faster and our app is faster.  A month 
> of optimisation could easily result in no benefits because what developers 
> think is slow rarely matches what *is* slow unless the developers have 
> carefully profiled their application.
>
> The problem, as has been pointed out, is that ENCAPSULATION is so terribly, 
> terribly important -- and almost always more important that 
> micro-optimisation -- that throwing away the known, constant benefits of 
> encapsulation for unknown, occasional benefits of micro-optimisation would be 
> a very, very bad idea for the community in general.  It might be OK for you, 
> but it's not OK for me.  Without encapsulation, it's much harder to trust the 
> correctness of my app.

I don't want to break encapsulation and that was the point of the
question. Toby mentioned req->params->{} and that will be the method
I'll stick with. I simply want to try and use the methods that will
provide the most dividends and for that to become habitual.

Thanx,
Dp.

___
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] Alternatives to Catalyst ?

[Ovid]

- Original Message 
> From: Dermot 


> Why wouldn't you, as you write, use the the fastest access methods
> available? Surely you'd want to develop habits that will a) provide
> better performance and b) as mentioned below avoid the thorny
> side-effects of req->params().  This isn't a matter of premature
> optimisation but simply establishing good practise.


This is a very common trap that many developers (even experienced ones) get 
caught up in.  Let's make *everything* faster and our app is faster.  A month 
of optimisation could easily result in no benefits because what developers 
think is slow rarely matches what *is* slow unless the developers have 
carefully profiled their application.

The problem, as has been pointed out, is that ENCAPSULATION is so terribly, 
terribly important -- and almost always more important that micro-optimisation 
-- that throwing away the known, constant benefits of encapsulation for 
unknown, occasional benefits of micro-optimisation would be a very, very bad 
idea for the community in general.  It might be OK for you, but it's not OK for 
me.  Without encapsulation, it's much harder to trust the correctness of my app.

In other words: give me a slower, but correct application over a faster, but 
unreliable one any day of the week.

Of course, if you can think of a way of dramatically improving the performance 
of the accessors without violating encapsulation, I'm sure patches would be 
gratefully received.

Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog - http://blogs.perl.org/users/ovid/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6



___
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] Alternatives to Catalyst ?

[Ben van Staveren]

Why wouldn't you, as you write, use the the fastest access methods
available? Surely you'd want to develop habits that will a) provide
better performance and b) as mentioned below avoid the thorny
side-effects of req->params(). This isn't a matter of premature
optimisation but simply establishing good practise.

  
Because if you are working with, say, 10 people on a team, and you will 
have everyone merrily doing direct hash accesses, sooner or later, 
someone's going to fuck it up and something will break in a spectacular 
fashion.


If you have methods to do this, the methods can check various things, 
and throw out the proper errors.


Yes, a little bit of overhead -- the cost of hardware to compensate for 
this overhead is still less than the cost of a fuckup that will keep 
your app bugging for the rest of it's lifetime.


--
Ben van Staveren
phone: +62 81 70777529
email: benvanstave...@gmail.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] Alternatives to Catalyst ?

[Dermot]

On 26 April 2010 11:22, Zbigniew Lukasiak  wrote:
> On Mon, Apr 26, 2010 at 10:57 AM, Ævar Arnfjörð Bjarmason
>  wrote:
>> On Mon, Apr 26, 2010 at 09:36, Dermot  wrote:
>>> On 21 April 2010 18:01, J. Shirley  wrote:
 __END__
 Benchmark: running all, low, sep for at least 1 CPU seconds...
       all:  1 wallclock secs ( 1.11 usr +  0.00 sys =  1.11 CPU) @
 2917341.44/s (n=3238249)
       low:  0 wallclock secs ( 1.27 usr +  0.04 sys =  1.31 CPU) @
 12930179.39/s (n=16938535)
       sep:  1 wallclock secs ( 1.21 usr +  0.01 sys =  1.22 CPU) @
 3223081.15/s (n=3932159)

 Subroutines suck, lets all use hashrefs.
>>>
>>> Now that it's quietened down, I can ask a question. Does this I mean
>>> it's preferable to use
>>>
>>> $c->req->{parameters}->{foo}
>>>
>>> rather than
>>>
>>> $c->req->param('foo')
>>>
>>> Obviously I'd rather use the faster method but if I'm breaking the
>>> encapsulation in some ways that's going to bite me later, I'd steer
>>> clear.
>>
>> "Obviously".
>>
>> Unless you're doing method calls in a tight loop somewhere in your
>> code you *shouldn't care about this*. Now I've written code that
>> actually *did* suffer from method call overhead but since you're just
>> casually asking it's very unlikely that you're doing the same.

Why wouldn't you, as you write, use the the fastest access methods
available? Surely you'd want to develop habits that will a) provide
better performance and b) as mentioned below avoid the thorny
side-effects of req->params(). This isn't a matter of premature
optimisation but simply establishing good practise.

>> Don't sprinkle premature optimizations around your codebase just
>> because someone produced a benchmark showing one is faster than the
>> other. You should be doing *profiling* of your  entire program, not
>> micro-optimizing something that's likely 0.0001% of its total runtime.


> This is a fine advice - but unfortunately the ->param method call
> suffers from additional problem - which is described in much detail in
> the documentation (go to the NOTE at:
> http://search.cpan.org/~bobtfish/Catalyst-Runtime-5.80022/lib/Catalyst/Request.pm#$req-%3Eparam)


I had seen this warning about the use of req->params() and lists.

So $c->params->{foo}  is preferred [1].

That's fine. Thank you all.


1)  ~/lib/Catalyst/Request.pm#$req->parameters

___
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] Alternatives to Catalyst ?

[Zbigniew Lukasiak]

On Mon, Apr 26, 2010 at 10:57 AM, Ævar Arnfjörð Bjarmason
 wrote:
> On Mon, Apr 26, 2010 at 09:36, Dermot  wrote:
>> On 21 April 2010 18:01, J. Shirley  wrote:
>>> __END__
>>> Benchmark: running all, low, sep for at least 1 CPU seconds...
>>>       all:  1 wallclock secs ( 1.11 usr +  0.00 sys =  1.11 CPU) @
>>> 2917341.44/s (n=3238249)
>>>       low:  0 wallclock secs ( 1.27 usr +  0.04 sys =  1.31 CPU) @
>>> 12930179.39/s (n=16938535)
>>>       sep:  1 wallclock secs ( 1.21 usr +  0.01 sys =  1.22 CPU) @
>>> 3223081.15/s (n=3932159)
>>>
>>> Subroutines suck, lets all use hashrefs.
>>
>> Now that it's quietened down, I can ask a question. Does this I mean
>> it's preferable to use
>>
>> $c->req->{parameters}->{foo}
>>
>> rather than
>>
>> $c->req->param('foo')
>>
>> Obviously I'd rather use the faster method but if I'm breaking the
>> encapsulation in some ways that's going to bite me later, I'd steer
>> clear.
>
> "Obviously".
>
> Unless you're doing method calls in a tight loop somewhere in your
> code you *shouldn't care about this*. Now I've written code that
> actually *did* suffer from method call overhead but since you're just
> casually asking it's very unlikely that you're doing the same.
>
> Don't sprinkle premature optimizations around your codebase just
> because someone produced a benchmark showing one is faster than the
> other. You should be doing *profiling* of your  entire program, not
> micro-optimizing something that's likely 0.0001% of its total runtime.
>

This is a fine advice - but unfortunately the ->param method call
suffers from additional problem - which is described in much detail in
the documentation (go to the NOTE at:
http://search.cpan.org/~bobtfish/Catalyst-Runtime-5.80022/lib/Catalyst/Request.pm#$req-%3Eparam).



-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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] Alternatives to Catalyst ?

[Octavian Rasnita]

From: "Ævar Arnfjörð Bjarmason" 
...

Now that it's quietened down, I can ask a question. Does this I mean
it's preferable to use

$c->req->{parameters}->{foo}

rather than

$c->req->param('foo')

Obviously I'd rather use the faster method but if I'm breaking the
encapsulation in some ways that's going to bite me later, I'd steer
clear.



"Obviously".

Unless you're doing method calls in a tight loop somewhere in your
code you *shouldn't care about this*. Now I've written code that
actually *did* suffer from method call overhead but since you're just
casually asking it's very unlikely that you're doing the same.

Don't sprinkle premature optimizations around your codebase just
because someone produced a benchmark showing one is faster than the
other. You should be doing *profiling* of your  entire program, not
micro-optimizing something that's likely 0.0001% of its total runtime.



If I remember well $c->req->param() is not recommended, but not for 
performance reasons.


It resembles the method with the same name from CGI.pm, and it can return 
not only a scalar value, but it could also return an array if it is called 
in list context. So it might break the code if multiple values were sent for 
the same variable.


Octavian


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 5061 (20100426) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.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] Dist::Zilla + Catalyst?

[John SJ Anderson]

On Apr 25, 2010, at 12:10 , Ævar Arnfjörð Bjarmason wrote:

> On Sun, Apr 25, 2010 at 15:39, John SJ Anderson  wrote:
>> Is anybody using Dist::Zilla in combination with Catalyst? If so, are you 
>> just not using it to generate your Makefile.PL or are you working around the 
>> issues that presents in some other way?
> 
> I'm using it for a plugin I have (Catalyst::Plugin::Upload::Digest).
> What issues are you talking about?

I'm sorry, I thought that the location of 'Home' was set based on the 
Makefile.PL. Reviewing the documentation, I see a dist.ini file can also serve 
for that purpose. 

thanks,
john.


___
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] Alternatives to Catalyst ?

[Ævar Arnfjörð Bjarmason]

On Mon, Apr 26, 2010 at 09:36, Dermot  wrote:
> On 21 April 2010 18:01, J. Shirley  wrote:
>> __END__
>> Benchmark: running all, low, sep for at least 1 CPU seconds...
>>       all:  1 wallclock secs ( 1.11 usr +  0.00 sys =  1.11 CPU) @
>> 2917341.44/s (n=3238249)
>>       low:  0 wallclock secs ( 1.27 usr +  0.04 sys =  1.31 CPU) @
>> 12930179.39/s (n=16938535)
>>       sep:  1 wallclock secs ( 1.21 usr +  0.01 sys =  1.22 CPU) @
>> 3223081.15/s (n=3932159)
>>
>> Subroutines suck, lets all use hashrefs.
>
> Now that it's quietened down, I can ask a question. Does this I mean
> it's preferable to use
>
> $c->req->{parameters}->{foo}
>
> rather than
>
> $c->req->param('foo')
>
> Obviously I'd rather use the faster method but if I'm breaking the
> encapsulation in some ways that's going to bite me later, I'd steer
> clear.

"Obviously".

Unless you're doing method calls in a tight loop somewhere in your
code you *shouldn't care about this*. Now I've written code that
actually *did* suffer from method call overhead but since you're just
casually asking it's very unlikely that you're doing the same.

Don't sprinkle premature optimizations around your codebase just
because someone produced a benchmark showing one is faster than the
other. You should be doing *profiling* of your  entire program, not
micro-optimizing something that's likely 0.0001% of its total runtime.

___
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] Alternatives to Catalyst ?

[Tobias Kremer]

> Now that it's quietened down, I can ask a question. Does this I mean> it's 
> preferable to use
> $c->req->{parameters}->{foo}
> rather than
> $c->req->param('foo')

AFAIK, the preferred way is:

$c->req->params->{ 'foo' }

--Toby

___
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] Alternatives to Catalyst ?

[Dermot]

On 21 April 2010 18:01, J. Shirley  wrote:

>
> __END__
> Benchmark: running all, low, sep for at least 1 CPU seconds...
>       all:  1 wallclock secs ( 1.11 usr +  0.00 sys =  1.11 CPU) @
> 2917341.44/s (n=3238249)
>       low:  0 wallclock secs ( 1.27 usr +  0.04 sys =  1.31 CPU) @
> 12930179.39/s (n=16938535)
>       sep:  1 wallclock secs ( 1.21 usr +  0.01 sys =  1.22 CPU) @
> 3223081.15/s (n=3932159)
>
> Subroutines suck, lets all use hashrefs.


Now that it's quietened down, I can ask a question. Does this I mean
it's preferable to use

$c->req->{parameters}->{foo}

rather than

$c->req->param('foo')

Obviously I'd rather use the faster method but if I'm breaking the
encapsulation in some ways that's going to bite me later, I'd steer
clear.
Dp.

___
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] Using Jquery UI Autocomplete widget with Catalyst::View::JSON

[Ben van Staveren]

Probably not the most pretty one but:

Given you have a resultset obtained with, say,

my $result_set = $c->model('DB::Somedata')->search_rs({...}, {...});

$c->stash->{json} = [
 map { id => $_->id, label => $_->name } ($result_set->all)
 ];

Or a bit more verbose:

foreach my $result ($result_set->all) {
 push(@{$c->stash->{json}}, { id => $result->id, label => $result->name });
}

  `

Hetényi Csaba wrote:

Ahh!

That was the trick :)))
(expose_stash => 'json')

Now it is correctly translate the perl arrayref datastructure to JSON 
array ( [ ... ] )


my @aoh = (
{
   value  => "1",
   label => "betty",
},
{
   value => "2",
   label=> "jane",
},

{
   value => "3",
   label=> "marge",
},
);
$c->stash->{json} = \...@aoh;
$c->forward('View::JSON');

:)

Thanks Ben!

One last question: if I have a DBIx resultset, how to use it to
populate autocomplete with the easiest way?

Best wishes from Hungary!




Ben van Staveren írta:
You can do that with View::JSON :) Just read the docs though, the 
reason it didn't work is that you put your data in


$c->stash->{json} = [ ... ]

And View::JSON will attempt to turn your entire stash into JSON data 
:) And it does that bit correctly, but the thing you end up with is


{
 json: [ ... ]
}

And autocomplete doesn't like that. So, either do:

$c->stash([ ... ])

Or set the expose_stash setting. Whatever is set in there, is the 
only thing that View::JSON will attempt to serialise.


Personally I prefer expose_stash => 'json', so that anything under 
$c->stash->{json} is serialised, but up to you :)










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



--
Ben van Staveren
phone: +62 81 70777529
email: benvanstave...@gmail.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] Using Jquery UI Autocomplete widget with Catalyst::View::JSON

[Hetényi Csaba]

Ahh!

That was the trick :)))
(expose_stash => 'json')

Now it is correctly translate the perl arrayref datastructure to JSON 
array ( [ ... ] )


my @aoh = (
{
   value  => "1",
   label => "betty",
},
{
   value => "2",
   label=> "jane",
},

{
   value => "3",
   label=> "marge",
},
);
$c->stash->{json} = \...@aoh;
$c->forward('View::JSON');

:)

Thanks Ben!

One last question: if I have a DBIx resultset, how to use it to
populate autocomplete with the easiest way?

Best wishes from Hungary!




Ben van Staveren írta:
You can do that with View::JSON :) Just read the docs though, the reason 
it didn't work is that you put your data in


$c->stash->{json} = [ ... ]

And View::JSON will attempt to turn your entire stash into JSON data :) 
And it does that bit correctly, but the thing you end up with is


{
 json: [ ... ]
}

And autocomplete doesn't like that. So, either do:

$c->stash([ ... ])

Or set the expose_stash setting. Whatever is set in there, is the only 
thing that View::JSON will attempt to serialise.


Personally I prefer expose_stash => 'json', so that anything under 
$c->stash->{json} is serialised, but up to you :)










___
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] Using Jquery UI Autocomplete widget with Catalyst::View::JSON

[Hetényi Csaba]

Dear Ben van Staveren

Thank You, now it is working, but in this case, i don't know
why to use Catalyst::View::JSON, it is just a text formatting.
Later I'd like to use DBIx datasource to feed autocomplete plugin,
in this case i must manually build a special JSON formatted string.
Is there exist a better way?

Thank You!


Ben van Staveren írta:

Looks like you need to set

expose_stash => 'json'

in your config.





___
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] Using Jquery UI Autocomplete widget with Catalyst::View::JSON

[Ben van Staveren]

You can do that with View::JSON :) Just read the docs though, the reason 
it didn't work is that you put your data in


$c->stash->{json} = [ ... ]

And View::JSON will attempt to turn your entire stash into JSON data :) 
And it does that bit correctly, but the thing you end up with is


{
 json: [ ... ]
}

And autocomplete doesn't like that. So, either do:

$c->stash([ ... ])

Or set the expose_stash setting. Whatever is set in there, is the only 
thing that View::JSON will attempt to serialise.


Personally I prefer expose_stash => 'json', so that anything under 
$c->stash->{json} is serialised, but up to you :)


Hetényi Csaba wrote:

Dear Ben van Staveren

Thank You, now it is working, but in this case, i don't know
why to use Catalyst::View::JSON, it is just a text formatting.
Later I'd like to use DBIx datasource to feed autocomplete plugin,
in this case i must manually build a special JSON formatted string.
Is there exist a better way?

Thank You!


Ben van Staveren írta:

Looks like you need to set

expose_stash => 'json'

in your config.





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



--
Ben van Staveren
phone: +62 81 70777529
email: benvanstave...@gmail.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/