« July 2007 | Main | March 2008 »

October 26, 2007

Adoby Flex Testing 1,2,3

Just tinkering with the recently open sourced Adobe Flex platform. There is a lot of potential here for developing data-intensive rich internet applications (RIA) with this platform.

Why are people interested in Flex? One of the other developers in the U Libraries pointed me to Bruce Eckel's article on RIAs and Flex, as an example of how developers are beginning to see this technology.

I like Flex for creating bomb-proof, embeddable and highly interactive widgets; backend administrative interfaces; and the possibility of building cross-platform desktop applications that can easily speak to web-based applications. There are still plenty of things that Javascript would solve more easily and more elegantly, I should add. One always has to be very careful when purchasing a big hammar.

And, being the agile community that it is, Drupal is already on it with tutorials, modules, podcasts and screencasts.

The following, very, very crude example was derived from the tutorial resources listed above as I modified code presented there to create what follows - not much time in my schedule to say more here, but this definitely has got me thinking....


More information at Adobe - and check out their Accessability Page (I'd like to dig more deeply into this aspect).

Posted by Chad Fennell at 2:43 PM | | Comments (0) | TrackBacks (0)

October 2, 2007

Drupalcon 2007 - Day One

This is the first in a series of posts of my notes from Drupalcon 2007 Barcelona. My note taking more or less petered out the last couple of days for various reasons, so the following is about as long as these posts are going to get.

Apart from what I learned in the seemingly endless stream of useful sessions, by attending a Drupalcon I realized just how much of Drupal is locked up in the heads of core maintainers. That is not a criticism of the project, it's just a fact of life. It's also a case study on why "knowledge management" is so hard. Even when you have the tools (Drupal), capturing knowledge is as hard as effectively representing it to users, and that's not an easy thing. It's also a reason why developers interested in utilizing the platform should seriously consider attending the conference. I found the community to be open-minded, tolerant of newbies and full of brilliant people. An especially effective tactic, I've found, is to corner a developer over a pint.

With that, here's what I learned in school:

  • Form API - Jeff Eaton
    • Noteworthy Hooks
      • hook_elements (core)- "Allows modules to declare their own form element types and specify their default values."
        • Hook Documentation
        • Allows developers to craft complex form elements (ex an address field)
        • great for (AHAH) powered form elements (ex FiveStar)
    • Changes to Form API in D6
      • $op is dead
        • New API decouples form processing from submit button text (thank god)
        • Now, every single button can have its own submit/validation handlers (ex a preview only builds a preview
        • Image buttons now possible as well as a result
      • In hook_form_alter you can also now change a submit button to an image
      • Buttons can have new AHAH-properties - ex adding new fields (AHAH)
      • Form State
        • Forms now (in D6) can store data based on which state (aka step) it is in and move users to other steps, where they will have access to this data
        • You used to have to embed this into "fake" form fields (ex you could validate and pass form state along to next step)
        • Multi-step forms are now properly supported
          • There is no more special "multi-state" form - all forms are inherently multi-step
          • Set form state to 'rebuild'
            • can trigger this anywhere and the form will just reset to any given step
          • Cached data: you can, for example, allow users to fill out a form one stage at a time
  • Connecting to External Data Sources - Ken Rickard (http://therickards.com/)
    • Utilizes the settings.php file's DB config options
      • Can add a array for external db settings
    • You then use the db_set_active() function in your moduule to connect external DB
      • It's best to reset to default database connection after you get the data
    • You can turn results from external DB queries into nodes when you need them to be (ie "lazy instanciation" )
      • I used "lazy instantiation" on the EthicShare project w/out knowing the name - used in the module that allows users to post citations to groups. Citation data posted to discussion groups is updated only when it is edited to keep load on the DB to a minimum.
    • You can't connect to multiple database types using this method - you get name space collisions if you want to connect to mysql and pg
    • Always cache the data for external sources (particularly important if you're writing for a block)
      • Do this with cache_set() as per usual
      • I wonder if there might be cases where caching is not useful.
        • For example, we use Solr (not an external DB but an external data provider nonetheless). Solr is *extremely* fast, probably faster than Drupal's DB-based caching mechanism, particularly on very large sites.
    • Use hook_search(), hook_search_display() to tie search results into Drupal's search mechanism
      • Is there a potential for a performance hit on Solr results?
    • Use drupal_execute() to submit a form progromatically
    • Check out Yahoo Pipes - wow, this is a very, very cool set of search tools.
  • Image Handling in Core...for real this time - James Walker (aka "walka")
    • There are about 8 billion image-handling modules. So, there is a strong desire among the community to select key functionality from among these modules, integrate them and embed them into core.
    • A good deal of discussion is ongoing over whether or not images (and perhaps other media) should be decoupled from the node system. Right now, images are added as a node with a reference to a file or set of files.
      • As nodes, images get access control and all the other system features that go with the node system
      • Adding them as a "first class" system object, co-equal with nodes would require a good deal of rework within Drupal's APIs
      • There are loads of pros/cons that I am not able to capture here, but the above gives you a taste.
    • Morten (aka "The King of Denmark") foolishly agreed to help streamline the UI
    • There was a tension between the "big picture" of image handlin (no pun intended)
      • "Digital Asset Management" - ie a generic approach to all media types
        • A lot of work has been done on this, but it's just too much work to deal with right now. Also, it presents a big change from current practice and there is a desire to get this right on the first try
        • And..the simpler approach of addressing only images
          • It sounds like there is a good chance to get this into core for Drupal 7
    • Check out Image field (requires imagecache)

Posted by Chad Fennell at 12:48 PM | | Comments (0) | TrackBacks (0)