fansipans's Journal http://use.perl.org/~fansipans/journal/ fansipans's use Perl Journal en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-02-09T02:37:53+00:00 pudge pudge@perl.org Technology hourly 1 1970-01-01T00:00+00:00 fansipans's Journal http://use.perl.org/images/topics/useperl.gif http://use.perl.org/~fansipans/journal/ Using Data on the Web - Models, Persistence, Management http://use.perl.org/~fansipans/journal/37602?from=rss Originally posted to my <a href="https://napkindrawing.com/blog_view/aitciaageureesir">blog</a>.<br> <br> I've been drowning myself in jQuery and HTML+CSS at work, which has been awesome for coming up to speed with all the recent technical developments on the web.<br> <br> One thing that has piqued my interest quite severely is the integration of JavaScript with server-side environments. With a tighter binding between client and server code, we can write less code, have better test coverage, and truly refactor web applications across everywhere their business objects/rules live.<br> <br> After rediscovering <a href="http://code.google.com/p/joose-js/">Joose</a> (one of the guys on use.perl wrote it or helps write it I believe), and seeing <a href="http://code.google.com/p/joose-js/wiki/JooseOnGears#Database">one of their demos where Joose uses GoogleGears or HTML5's Database feature</a>, I really wanted a simple-to-use ORM for JavaScript. Without GoogleGears or HTML5 support this could also easily be done server-side by having a url that took standard orm requests (find/search/save/delete) and returned standard JSON.<br> <br> Now this sounds familiar.... oh right, that's a perfect description of <a href="http://incubator.apache.org/couchdb/">CouchDB</a>!<br> <br> CouchDB is another thing I've had a lingering fascination with. It is a document-based database written in Erlang, with a JSON interface. Data manipulation inside the database is performed by snippets of code that create "views" of the data. CouchDB ships with JavaScript support, and support for Perl exists in CPAN via <a href="ahref=">CouchDB::View</a>. It's one of those things you can see has HUUUUUGE potential, but really needs those little libraries that link it to other popular frameworks/platforms to really take off, or get that foot in the door with the web programmer zeitgeist.<br> <br> So according to this <a href="http://groups.google.com/group/jsonpickle/browse_thread/thread/62416a09528bbfc0">mailing list thread about work on Joose.Storage which mentions CouchDB</a> and this <a href="http://joose-js.blogspot.com/2008/08/joose-now-supports-jsonpickle.html">announcement that Joose supports the cross-platform serialization library "jsonpickle"</a>, I wonder what it would take to get that perfect easy API so in a Joose class all you'd have to add to your Joose class definition is:<br> <br> <i>does: CouchDB</i> <br> <br> That and maybe adding something like (totally making this up)<br> <br> <i>Joose.Storage.CouchDB.url="http://db.server.org/testing"</i> <br> <br> to the top of your javascript, and badabingbadaboom you've got versioned object persistence backed by one of the most awesome open-source high-performance databases out there!<br> <br> Edit: Looks like there's already a <a href="http://plugins.jquery.com/project/jqcouch">jQuery CouchDB plugin</a>, written by <a href="http://protoblogr.net/">Jerry Jalava</a> (<a href="ahref=">see announcement on his blog</a>.) It looks like a straightforward implementation of the CouchDB API:<br> <br> create(database_name)<br> connection(database_name | view_name)<br> get(document_name)<br> save(database_name, document)<br> all(database_name)<br> <br> I'd like to see a database-backed object persistence layer that can use that API, or a number of other APIs, such as:<br> <br> <b>1. A server resource/URL that receives the name of a database operation, and a JSON representation of the data.</b> This is nice because it's easy to implement with whatever server database / language / runtime you have. If this were a centralized project, it would be trivial for members of the community to support new server environment/database combinations. <br> <br> <b>2. JSON-enabled Database Servers.</b> Who wants to write the MySQL Server JSON connector? Or a generic JSON-to-Database bridge, which could support a standard JSON interface, and many different backend databases? The bridge could be configured with even more javascript to function as server-side validations or business logic.<br> <br> <b>3. SQL Dispatcher.</b> Pretty much the same as #1, but with the SQL generated client-side. This would still provide a JSON interface, and require parameterized queries.<br> <br> It seems to me that all of these ideas have been best expressed by CouchDB, but to acheive widespread adoption, I still have concerns with legacy systems, existing infrastructure, critical mass, etc. fansipans 2008-10-05T14:55:19+00:00 journal Storing Content "Within A Package" http://use.perl.org/~fansipans/journal/33290?from=rss Had a hilarious DUH moment yesterday. I was trying to figure out the best way for my CGI::Application application to bundle in all it's html templates into it's own package so when installed there's nothing other than the perl modules, no other directories / web pages / sites to set up..., everything is in<nobr> <wbr></nobr>/usr/lib/perl5/5.8.4/MyApp and the Templates are in<nobr> <wbr></nobr>/usr/lib/perl5/5.8.4/MyApp/Templates<br> <br> So I'm pondering, and pondering, thinking maybe I can tweak the low-level of <a href="http://search.cpan.org/perldoc?Petal">Petal</a>'s code into treating filenames and perl modules interchangably, and if using a perl module, read in from the __DATA__ section or something...<br> <br> Then I realize the entire problem is reduced down to one simple variable change to my cgiapp_init:<br> <br> <code> $self-&gt;template-&gt;config(<br> &nbsp;&nbsp;&nbsp;&nbsp;default_type =&gt; 'Petal',<br> &nbsp;&nbsp;&nbsp;&nbsp;include_paths =&gt; <b>\@INC</b> <br> ); </code> <br> <br> So now CGI::Application looks for my templates, and finds them, as pure html, no __DATA__ jibba jabba, just easy. Huzzah!<br> <br> DUH! fansipans 2007-05-16T14:06:53+00:00 journal Charlotte Perl Mongers Meeting http://use.perl.org/~fansipans/journal/33036?from=rss The Charlotte Perl Mongers will be meeting tonight, for time and location see the link below.<br> <br> The subject of the meeting is Perl vs. Ruby: Web Application Frameworks<br> <br> I'm giving the presentation on the Ruby side. I'll be going over the embedded server that ships with Ruby, WEBrick.<br> <br> We'll briefly present Perl's CGI::Application and Ruby's WEBrick, then compare and contrast between them. I think both topics will delightfully show how simple it is to put new and old code online quickly and easily, where the power of web browsers and remote agents can shine<nobr> <wbr></nobr>... with rainbows<nobr> <wbr></nobr>... and ponies. I like ponies.<br> <br> <a href="http://charlotte.pm.org/">Charlotte Perl Mongers Home Page</a> <br> <br> <a href="http://napkindrawing.com/charlotte_pm/webrick_presentation/">My Slides on WEBrick</a> fansipans 2007-04-19T15:01:44+00:00 journal Hello World / Perl Monks Question http://use.perl.org/~fansipans/journal/32819?from=rss Hello World! First journal entry... long time listener, first time caller...<br> <br> What motivated me to finally post is this simple sienfeldian question: "What is the deal with PerlMonks?"<br> <br> I'm looking at something that seems like the perfect troll<nobr> <wbr></nobr>... specifically:<br> <br> <a href="http://www.perlmonks.org/index.pl?node_id=606789">http://www.perlmonks.org/index.pl?node_id=606789</a> <br> <br> Highlights include:<br> <br> <cite>is there a way to make tty:// really log into a system from a browser</cite> <br><nobr> <wbr></nobr>...<br> <cite>I want to experiment with [making] a custom protocol that could be used between a system and its proper clients that avoids spinning the firewall by disabling all the usual protocols and only accepting a custom one</cite> <br><nobr> <wbr></nobr>...<br> <cite>so that customers can get on board by downloading a protocol installation kit as soon as they have a formal relationship (e.g. a financial account) whose registration can be automated rather than needing lower level network modifications or hardware.</cite> <br> <br> This post honestly made me laugh because it's got just enough technical basis to warrant "discussion", but it's so wildly silly if you actually know what you're talking about and it's received a fair amount of discussion and ideas around the pros and cons of implementation. Also, the person's nick is "Moron". And finally, what does this have to do <i>at all</i> with Perl? I can understand being <i>extremely</i> patient with new users, but threads like these really seem to lower the signal to noise ratio. <br> <br> Cheers,<br> Mike fansipans 2007-03-28T14:38:21+00:00 journal