« Perl 6 Summary: 2006-03 | Main | Random recaps. »



Feed You can follow this conversation by subscribing to the comment feed for this post.


I think I'll put Scalar::Defer to work immediately. Thanks!

It'd be nice to have something like LINQ in pugs...

Exciting times for Jifty! It appears to be going in all the right directions ;)

I'll have to re-evaluate using it for my next project. Right now, I use Catalyst because:

1) It has better documentation
2) DBIx::Class

Have you looked at or used DBIx::Class (DBIC)? I believe it would be a better ORM for Jifty than Jifty::DBI.

In some ways, it is a lot like DLINQ (which you referenced in Moosifying Jifty). I.e. an ORM which allows you to map relationships and build complex queries which defer translation into SQL until a resultset is needed.

It can roundtrip to a limited degree (which is getting better). I.e., you can generate the DBIC schema from the underlying database, or generate the database from the DBIC schema. Or if you wish, you can load the schema dynamically from the underlying database. It would be nice if the syntax for specifying a DBIC schema were like Object::Declare.

With DBIC you can create or use a pre-existing database with views, constraints,etc. Then generate the DBIC schemas and extend them as necessary. To my knowledge, working with pre-existing schemas is something Jifty::DBI::Schema doesn't do.

There's a versioning branch of DBIC which can diff the current DBIC schema and the underlying database's schema and update the latter. This is something Jifty already does.

Another thing Jifty::DBI::Schema does is allow the programmer to use Model-side syntax for View-side attributes. And it is very exciting to see that Controller-side actions will soon be supported. It'd be nice to see similar support in DBIx::Class.

However, I don't like the way that Jifty::DBI::Schema conflates Model and View. And Controller soon I imagine. I hope we don't see code like:

column colour =>
type is 'text',
default is 'blue',
is mandatory,
label is _'Colour',
render_as 'textarea',
valid_values are ('pink');

sub validate_content {
my $self = shift;
my $val = shift || '';
if ($val ne 'pink') {
return $self->validation_error( content => "That'll get you thrown off the bridge");
return $self->validation_ok('colour');

On the one hand, it'd be nice to have a common validation attributes. I'm imagining the autogeneration of clients side javascript form validation, server side form validation, and database table column constraints.

On the other hand 'label' and 'render_as' have no place in the data model.



ggoebel: Thanks for the kind words. :-)

You might be surprised to find that validator already works in model classes, and indeed Jifty isn't designed as strictly MVC -- its parts are quite non-orthogonal.

Thanks for taking the time to read and respond.

Yes. Jifty::DBI::Record calls validate_$column_name hooks before accessing the database. This abstracts 'constraints' above the specific database implementations. And it is fine if all access to the database will be through the Jifty app.

But preferrably, you'd be able to put data constraints in the database. Where are the gaurrantees for data integrity when Jifty isn't the only one accessing the database?

The Jifty philosophy appears to be that SQL and RDMS's are simply a means to a dedicated object store that should be kept as far from the programmer as possible.

My impression is that Jifty makes many tasks considerably easier. But from the database perspective it makes the hard jobs more impossible.

Which brings me back around DBIx::Class. Which makes many tasks easier, but still enables you to go in and do the heavy lifting when necessary.



Garrett: I've been talking with mst about Jifty::DBI shims on top of DBIx::Class. Just like Moosification, as long as there's a emulation/translation layer that makes migration possible -- and not slow down things -- I think a switch to DBIx::Class is totally reasonable.

That's encouraging.

It might be fun to work on that once I get my current project under control.

Hey, Audrey, when will Jifty pass its (horrible) test suit on Win32 please? Attempts to install Jifty to ActivePerl is really a pain at this moment. :-/

You know, I really can't wait to enjoy Jifty for my $job which requires Windows. :P

agent: Hmm? I also use Jifty at $job for Win32, and it should install fine there too. Try http://svn.jifty.org/svn/jifty.org/jifty/trunk/ and see if it works for you? Also you may want to try building from Strawberry Perl (http://vanillaperl.com/).

Oops! sorry, Audry.

I still fail to install Jifty's dependencies on Strawberry Perl. One example is Test::HTTP::Server::Simple. It complaints the lack of some signal ("No such signal: SIGUSR1") and segfaults eating up all of my CPU resources while running its test suit (just as the case when using ActivePerl). So I can't go any further.

Even on Cygwin, Jifty can't be installed without "force install" a handful of its dependencies. And still, it fails a lot of its own tests. Oh well...

Is it possible to remove some of the unportable dependencies (such as Test::HTTP::Server::Simple) completely from Jifty's test suit? I've never got Test::HTTP::Server::Simple working on Win32 IIRC.

I'm wondering how you managed to have Jifty running happily on Win32 long long ago. Maybe there's something tricky you haven't mentioned yet? Or will you make your Jifty's Win32 binary installation available from somewhere on the Internet so that others don't have to join the pain?

Thank you for your patience. :=)

agent: I think I did it by the way of "force install Jifty" or "notest install Jifty". :-) But a JiftyPerl is definitely something I'd like to work on after I finish my OSCON talk.


Sorry for the typo. :P

Indeed the idea of JiftyPerl is very cool. I'm looking forward to that.

I'm also looking forward to your OSCON talk on Web 2.0 and Jifty. :=)

The comments to this entry are closed.

December 2015

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31