Several tricks:
- There's WIA Scripting and WIA Automation. Oh and there's the STI API and TWAIN and PSC...
- WIA Automation is the version 2 of WIA Scripting and is the one to use.
- It's a COM API and it works neatly with .Net Interop and C#.
- There's some gotcha like the collections indexers cannot be used directly for some reason or Property.Value cannot be accessed directly from C#, etc. Workarounds are trivial such as using the GetEnumerator or get_Value()).
- WIA Automation works only with XP SP1 and above.
- I had to explicitly upload and install Canon's WIA driver for the Powershot S100.
- I had to uninstall the current Canon USB Twain driver for the WIA one to work... after a reboot.
Now using the WIA Automation API can be done in two ways:
- By doing nothing and relying on the ShowAcquisitionWizard. By nothing, I mean nothing but that call. The wizard is in the pure Windows spirit -- doing everything neatly in a generic way (from selecting which pictures, where to download them, which name, even proposing to use web-based printing, all with a neatly Digital Pictures for Dummies look and feel). Not what I want at all, yet a great feature for such a small DLL.
- Manually enumerate devices, items (images or folders) and properties of these items.
It's all very neatly generic. I guess I can limit myself to these specifications:
- Only download images from the root folder that are JPEG files.
- Properties I care for:
- "Item Name", the file name such as "IMG_6042.JPG"
- "Item Size", the file size in bytes
- "Thumbnail Data", "Thumbnail Width", "Thumnbail Height"
- "File Time Count" (looks like a time_t value) or "Item Time Stamp" (a COM Object, dunno which one yet).
- There are more properties or flags that I'm not sure about. I can ignore them right now.
- There's no obvious flag indicating if a picture has already been downloaded or not. That's not a problem, I can keep a little database of already downloaded pictures. I just need a unique identifier per image. Something like the Item Name and the Full Item Count will be more than enough (the later would be just enough).
How do I use all this?
- Create a C# Class Library.
- Ability to connect to the device manager and register the device detection event.
- The lib register the event and simply calls a delegate in the main form.
- Enumerate available cameras, if any (refresh on device event).
- Enumerate images available on the camera.
- Download the nth image.
- The host application is a simple .Net Windows.Form.
- Create an instance of the class lib at startup.
- Two panes to display the disk album tree: explorer pane and album view (recursive).
- In the explorer view:
- Create new folder.
- Rename album.
- In the album view:
- Cache thumbnails in a temp folder (refresh when modified).
- Select, Rotate, Fullscreen view (with manual slideshow prev/next), Rename.
- Rename group with regexp ("IMG_([0-9]{4})\.JPG" => "\1_Image.jpg").
- A third pane (or better simply a new window) to display the content of the connected camera(s). If there is more than one device, select using a popup.
- Indicate if item already downloaded (simply text db with device name + item name/item date).
- Flag images to download (default: all new).
- Download.
- Prefs:
- Disk album location.
- A regexp to filter items displayed in the camera window (such a "/\.JPG$/i").
- A regexp to filter items displayed in the disk window.
Features not present, I'll see later:
- Delete images from the camera.
- Synchronize with RIG album.
- Delete non-empty folders.
- No DB for thumbnails (ideally I just need to read them from the EXIF...)
20041218 Update: WIA Automation Run-Time Requirements (extracted from MSDN):
The "RIG Photo Browser".
Here's something I was thinking about a while ago:
I use Canon's Zoombrowser software to download the pictures from my digital camera.
I like it especially because of the graphical overview display of the albums
and of course because of the seamless connection with the camera.
I particularly enjoy these features:
What I don't like:
There are many features that I don't really care for (external image editor, backup,
multiple DBs, editing EXIF info, etc.)
Quite frankly, the only really irritable issue is the dialog for confirmation.
So here's the deal:
There's many more features that can be planned in this stuff, see the
earlier post for more. I won't go there right now. I want something simple
just for me, not a generic project.
What's up with RIG?
Currently I'm experimenting with modules and an OO design.
I'm not sure how perfect it is, yet it should be OK for a start.
Now the question is where do I want to go?
Ideally I'd like to reorganize the code using this modular design.
It's my belief that one of the problem with open source projects is that developers
regularly waste their time by throwing their actual version and rewriting it from
scratch. That's a very bad habit since the project gets delayed, new bugs are
introduced, users have to wait for the new version to be developed, tested, debugged
and brought to at least the same level of functionnality as before...
Instead a better approach is the iterative concept of XP.
Refactor some code piece by piece (which is not the same as throwing it all out at once).
It allows for the project to evolve too.
Note: if you don't care about open source stuff, think in terms of business software
and tine-to-market... the problem is the same. Iterative evolution allows to keep
pushing new version with new features whilst rewriting from scratch delays new versions.
So here's the deal for RIG:
So the idea here would be to implement the barely minimun to get the module system
working and then use it to add the comment feature. That means technically only
the RModuleManager and the RModComment are needed. I might throw in RModCss in the process.
Later I will want to add some useful minor features I experimented in Izumi lately,
name page stats and page logs. Same, these should be made modules and included in the
non-module actual processing.
Let's talk templates now.
The template stuff is needed too but I'm not quite sure about how to design it right now.
Currently the code that handles the album or image logic also generates the tables manually.
That means I couldn't write a template module that is generic and clean and yet relies on
the current code without rewriting major portions of it.
Ideally I want to really separate the logic from the rendering code.
So templating of existing stuff will wait. On the other hand it may be nice to introduce
templates only for new features, such as the comments.
I had an idea of templates that was basically wrong imho.
Currently for the album list, for example, I have a PHP page that calls PHP functions
to insert the sub-albums table, the images tables, the options, etc.
What I though I'd do is a template file that would not be PHP code and would contain
tags that would call some module's functions (think XUL, ASP or JSP tags, without the XML
syntax).
This doesn't quite solve the problem; in the specific case of the album table, there are
in fact two things I need:
This is quite obvious actually, I realize the concept is already present in many web sites
and is inherent to CSS: boxes, or "<div>". A page is made of a succession of boxes:
title, album table, options, comments, credits, etc. A page template will specify things
such as colors, which boxes are present and where they should go. The layout part could
mostly be done using <div> with an inner RIG tag.
(An approach with XML "HTML-compatible" tags would be even nicer, where the RIG tag
could contain div style attributes, which the module code would read. Then the module code
would generate the div tag itself; so for example the size would be known, etc. This is
more generic... let's do that later.)
Then each module needs its own template for its own box.
Obviously there could be a number of generic boxes:
Modules would then use these generic box templates. For example the album table and
comments will most likely use the bordered box, whilst the options will use the section box.
A template then becomes a collection of these:
Is a template a PHP file or a custom file? Maybe both. There could simply be a template
manager that has two options: interpret that file, and call that function (should be
recursive too.)
Finally each module needs to provide its own default template (either by a string,
or function or an external file) and then we need a system to allow existing templates
to override that. Parts which are not redefined should be inherited from the default.
Well, that's for the theory. For the details of the implementation, we'll see later :-p
The way options are stored is far from perfect.
Currently for whatever album directory tree, a similar tree is created in the options
directory. Each sub directory contains only one option file.
The problem with that structure is not the storage method per se.
It's that whenever the album tree is modified, options do not follow
and keeping them in sync is usually annoying.
What are the alternatives?
Storing the options files directly in the album directories is one.
It's actually already possible by setting the options directory name to the album
directory one (and making sure PHP has write access to these directories).
Icons are still a problem since a directory options contains the explicit name of the
file used to generate the icon. Whenever that name is no longer valid, the icon is
regenerated using a random existing file.
In the module management, filtering the query using a regular expression may not
be enough. For example if module 1 wants query arguments A and B and module 2
wants query arguments A, B and C, which module is going to get loaded versus which
one should get loaded?
Currently the entry point PHP function checks modules in a specific order.
The module manager should do the same. The order could be specified using an
integer value in the description block -- a priority index so the higher this value
the earlier this module will be tested.
RIG does not use session data.
Instead information is transmitted from request to request using
explicit query data. The purpose of such is that when following a link
it is enough to bookmark the URL to get the exact same page later.
The obvious inconvenience is that URLs tend to be long and verbose.
In the current monolithic architecture, the generation of the URL request
for a new link is generated by a single function that takes into account
the current context (image or album name, page number) and optional arguments
that override these values.
In the context of modules, this may be a bit harder to use. One centralized
function could not grow to handle any attribute of any unknown module...
For example album pagination could be handled by a separate module,
rather than built in the album module (not that it would be the most
efficient, imho). In this case, say RModAlbum would need to generate a new
link with "&album=..." and somehow it should know that the pagination
module needs to include "&page=...". Now if some other auxilliary module
is plugged in, how should RModAlbum know about it?
Three possibilities:
Started working on classes for modules as explained below.
This is what I got yesterday:
This is OK, nothing seriously surprising here.
This is of course experimental at best. I first want to see how it fits together by implementing
as less as possible (just a module manager, a template manager, the album module and a default
template) and see how it behaves.
One of the interesting questions I came accross is "what is a module?".
Two options here:
Both approaches are equal, in the end, more or less -- from a end-user perspective definitively.
From an administration perspective and development perspective, those two approaches are
radically different. The obvious idea is that a module carries the notion of optional.
If something is a module, it can be either enabled or disabled.
For example, consider the login management (normal and/or admin). Currently that is built-in
(since the whole PHP application is monolithic). If it was made a module, RIG should still
work if this module was disabled, except there would be no authentication.
Same for CSS support, cache, etc.
Now some module will need to be core module. Some others will need to work together.
For example if RModStrings provide UI-translated strings, RModRigAlbum couldn't really work without
it. Same if the template management was made a module. Everything that relies on template display
should require this module.
OK so modules are good. Ideal even since a module won't be loaded (i.e. its PHP parsed) unless
it is used, so only the necessary PHP code will be actually parsed.
Now, how do all these modules communicate together? How can the album management work with
an optional login mechanism (which may provide user rights managements) and an optional cache,
an optional options, etc.?
Part of the answer is in a predefined workflow. Another part is hooks. And the final part is
it's the module's problem. Let's detail:
Some modules will obviously rely on others. For example to diplay a RIG album, a template will
be used. That template will itself refer to a module that contains code dictating how to display
things. Eventually there could be auxiliary modules that provide different formatting for the
same template.
BTW since modules are not loaded before actually being requested, there should be a way for the
module manager to know when to load modules. This can be a pattern in response to a query or
it can be a module that always want to be loaded, or in reply to some hook, etc.
This information could be present in textual form in a separate text file, one per module.
Or it could be embedded in the PHP file itself (as a comment with a specific tag).
The module manager will need to read all these files are startup before even deciding
if any module needs to be loaded. Ideally it could cache all this info into a single text file
and refresh it only if the source tree as changed.
There's still a lot of planning to do to get this thing up and running.
My ideal is to provide a mechanism that is simple yet flexible and eventually have to write
the less possible code to make it work. That means it may not start all as fancy as what has been
said here. It will evolve with time.
I just wrote this post: commenting photo albums.
That gives some interesting ideas with the kind of comment system I need in RIG.
Now these are just ideas and here I'm just talking about stuff useful for me.
Sounds selfish?
Hey, I'm the first user of RIG after all :-)
So the ideas are:
The dual mode is really a good idea. AR's feedback was that having a real comment system was overkill for him (even for me)
and anyway it couldn't scale as well as a complete BBS system, yet Sum could use it. So have these dual mode is not too
complicated and should make everyone happy.
This last one would be good enough to do the same as my previous hand edited comments with side-by-side English/French
text. There are many options here:
Some ideas:
So yeah just poping a little dthml window that shows the albums or images contained in
an album when the mouse hovers over the thumbnail. If there are no sub albums, only
a selection of images should be displayed.
Similarly when viewing images of an album, there could be a little poping preview per page.
OK maybe that one is too much. But at least it's a bug that when using the link "back to
album" from an image it doesn't go back to the album page containing that image.
Once I have templates, I could have several templates for albums: simple (not dhtml),
with hover previews and full overview.
The current plan is to cleanup the existing code before starting adding new features.
By cleanup, I mostly think finished what has been started:
Once this is done, the code will be a 0.7 stable.
And from there I can think of adding these features, with no preference order yet:
Ideally once all these features are in place, I have a version 1.0 (and of course there's still
room for more wanted features such as group management, image options, slide show, etc. -> 1.1+)
I'm not sure of the order yet. It would logical to have it in the order listed above, with
the new OO being inserted first and then map the existing functionality on top of the new
system, ideally with some testing to make sure things continue working
(may I mention that I have no clear idea at all how to apply regression testing to a PHP
page on its whole? phpUnit only helps at the TDD/function level).
Regarding comments, I'm not sure exactly what I want, so I'll describe my current idea here
and feel free to enhance/change it later.
Comments should have the following property, as described thru the preferences:
Now, if comments are enabled, they will be listed at the bottom of the page (the idea being that
with the CSS/template stuff eventually one can place them anywhere they want). Ideally I'd like
a summary mode with only the N last comments displayed on a page and a "Read more..." button to
view a comment thread in a different page. That will be for stage 2 of the feature but it
influences how I store them.
I will not do threaded comments at first, just a flat model.
Also there should be a link to add a new comment, that would bring a new page with a text box,
a thumbnail of the image or album being commented and the user info if applicable. Oh and
comments will be entered in Izumi/wiki syntax, no HTML allowed, so the page should also list
the most usual Izumi syntax commands. Next I need preview & post buttons.
What do I need next? As requested, I would need a way to view the N most recent comments site
wise (in fact, it could be "album wise" to view the N last comments of any sub albums or images).
I'm not sure how costly that can be.
Implementation wise, there are many possibilities and I'm not sure what I want yet.
An idea was to simply keep one text file per album or image with all the comments.
A similar idea would be on DBM file, which would then grow more realistically.
The other idea submitted by Sum was to create one text file per comment, with the name being
a combination of source IP and/or time and/or process id (to make sure names are unique).
It requires more access to view all comments but it makes it easier to just grab the last N ones
and it simplifies the overall management (like deleting one comment... can be done manually from
the shell).
I should reconsider my position on the GPL and use it for RIG or
at least make sure I use the latest Artistic License.
Idea for RIG:
The idea is:
Since I will obviously not support sublanguage codes, the test should be done on the major
part of the language code, i.e. "fr-FR" should be treated the same as "fr". This may be in
violation of the corresponding RFC (which I haven't checked) yet. Users are supposed to
put in a generic language code after a more specific one, i.e. having a setting typically
like "en-GB, fr, en". In this case following the rules, RIG should select "fr", not the
first "en". Can we trust users to do that?
Most users won't change their settings. I noticed the following:
Also, RIG should not set cookies that are default values the first time.
The first benefit is it avoids the "accept cookie" dialog the first time a client connects to RIG.
The second is simply the less cookies, the better. Most think cookies are evil and are right.
Storing useless cookies is a bit of an abuse and lazyness on my part.
First I'll log all the language settings I receive in RIG and Izumi and see what they look like.
It's time I reconsider using ImageMagic and other "out-of-the-box" tools (like the PHP's interface to jpegs and exifs).
The idea whould be to have 3 levels of support:
Using ImageMagic as an external app could be simply achieved by calling a script that calls either rig_thumbnail or IM.
Also I bet any other tool could be used instead of rig_thumbnail to extract the video type and thumbnail, but that is left
as an excercise to the user which is stuck on a system where it couldn't build rig_thumbnail yet would have a suitable tool
(very unlikely, imho).
Also maybe I should stop being lazy and really improve rig_thumbnail's speed, as per the comments I received last year
(using the EXIF data as a base, or the DTC-8 coefs).
"I dunno, man, that sounds like a lot of work" :-)
I recently found the nice Creative Commons licences.
I should use that for my Imzumi and RIG albums. The easiest way is to embed the XML/RDF in the generated pages,
by using the customizable CSS header variable (which is a site/album pref). That way, there's no need to change the
album/images templates. For RIG, I can also override the copyright holder name variable (also a site/album pref) to put
in the blurb saying that it's a CC license with an image link, and maybe have it be a link on another static HTML page
that explain what is is all about in simple words.
There is no way to currently embed the CC verification link in images (I mean not officially yet). I'll bet this will
come soon, as for JPEG it's not too hard anyway.
Another day, another idea: a GUI to control RIG sites.
My workflow to update my RIG albums is generally simple:
First I upload photos on my desktop
in a temporary folder using Canon ZoomBrowser.
Then I generally rename the images locally using a bash script in cygwin.
Then I refresh ZoomBrowser database and move the albums around to get the hierarchy I
like.
Eventually I rsync or use Windows Explorer to copy the album to the server over Samba.
The next phase is to view the albums in the browser, hide albums, hide/show images, etc.
I like this process because of the GUI offered by ZoomBrowser. It's nice to have a GUI to
visualize the structure of the site, a feature which will be available in next RIG's version
but for browsing only.
Now what I'd really like is to get rid of ZoomBrowser and its few defects. The major problem
I have with ZB is that it does not refresh its database when the filesystem changes; it's not
automatic; there's a refresh option which then is smart enough to notice when images have been
moved around. On the dumb side, it asks for confirmation of rename or move operations for every
touched images, without a much needed "apply for all" option.
So a solution would be to get rid of ZoomBrowser by replacing it with my own GUI. It's some
work, but it's doable if I keep it down to the features I need:
To be useful to most, this would have to be both a Windows app and a Linux app.
My current trend is to develop in C#/VS.Net (it's really a cool environment for RAD). I'm not sure
I would be able to pull this off correctly on the Linux side by relying on Mono and GTK# right
now, but it's worth the try. The other option is a Glade/C++ dev, which could be good for a
multi platform dev.
C++ lacks a rich framework of utility classes (and no I don't do STL) and is really not a suitable
environment for unit testing, but it can offset that with a good level of performance and
portability.
One more project? Depends on the demand and my motivation. To be seen.
The results of what I want to redesign in RIG.
A todo list would be in that kind of order (by decreasing priority):
Idea: design a target OO layout that includes izu; then design a temporary OO/modules that matches the existing towards
the ideal design. To transform, design phpUnit tests that match the existing and pass before & after the design change.
Another approach is not to reorganize at all; simply create new classes that encapsulate the existing code with the same
behavior.
Both approaches are similar. The emphasis is on evolving the current functionnality rather than writing it all from
scratch. Note that this has been mentionned several times in open source software critizism -- the tendency is for
authors to throw away the design and start it all on fresh bases. This has the advantage of a supposedly clean design
without the cumbersome past history of the code (read: "mess"), but it has the major disavantage of slowing the evolution
of the project (the new design will take time to implement, and will probably be full of bugs at first). A better approach
is to keep the existing functionnality (I mean really keep the code just as-is) and evolve it. In RIG's case, my idea is
to have a compatible OO structure where new classes would merely call the existing functions. Then when it all passes
phpUnit tests, if needed, it would be possible to move the content of the functions into the classes methods.
This is similar to how I did Izumi: using RIG's code, I simply added a couple of classes to handle path and page
management, whilst keeping all the code from the common sources. I did not rewrite code, simply add new one. The
common sources do not need to change.
So what's in the existing RIG code?
Good points are:
The last point is the key one: the actual code is just fine as long as I do not want to add comments, templates, izumi
and the possibility to cross reference rig pictures in izumi and vice versa. Then it will become harder and harder to
follow. Thus the need to plugin new stuff using a better OOized design.
There are a couple of things I want, corresponding to the following vocabulary:
Modules: They provide one "chunck" of functionnality, which are implemented using one or more classes (the lesser the better).
There should be a module manager which purpose is to initially list modules and then be able to instantiate one
as needed. The notion of module should be pretty generic. There should be:
Templates: The rendering of the pages will be template driven.
Media: Currently RIG uses the terminology of albums containing images or videos; Izumi has directories containing pages.
All these are kind of a media. A media can be a page, an album, an image, a video, even a Zip archive. A media type is
identified by its name (a pseudo mime type, such as image/jpeg or video/mpeg or izumi/page or rig/album maybe).
There should be a media info class that represents the information RIG knows about a given instance of a media,
typically: paths (location, cache, self url), title, access rights, and options.
Then we would have the following hiearchy:
Given all this stuff, the ideal structure and workflow would look like that:
Some auxiliary modules and their workflow:
There are a couple more points to detail but that is the bulk of the idea and is enough for today.
OK I'm lame. I never though about that one before: what is the point of being able to hide accesses to images
if anyone can browse the preview cache directory or the source directory by using it's direct URL?
I guess I could have an .htaccess that prevents browsing there. I should (ok... done here!).
But that should hide the fact that RIG
should not require the directories to live under the web server's document root. Instead, what I realized lately,
is that RIG should serve the images directly; I really mean the access to the images should be done via the
index.php script with some specific query arguments. That way, images can be stored anywhere one wants on the server,
it wouldn't even be necessary to have symlinks in the script's base directory.
The other idea is to prevent viewing images directly, i.e. not from the containing web page. That's because RIG
access to image above will not allow for checking things such as user credential and page visibility for a given
user group (whenever RIG support those of course). If someone has a RIG url pointing on a direct image, s/he'll get the
image. Sometimes that is not acceptable.
It doesn't seem quite easy to perform such a limitation. One lousy way would be to encode some client properties in the
URL that is requested: a time stamp (for expiring the request), the referer host and maybe the agent string (or rather
a hash of all these). Now I realize that if RIG's script is evaluating the request, it also has access to the request
headers, thus the cookies. That can be used to perform user credential validation.
One of the features I want to add to RIG is the ability to have user add comments
(enabled in the prefs per album of course).
On one hand. in between I've been working on Izumi, and one of my ideas was to
merge in into RIG at some point (for a background on the izumi syntax, see IzumiTextSyntax).
On the other hand, I do not like people being able to insert HTML in comments and in description files.
When you own your own server like I do, you can trust yourself not to insert cross-scripting issues in the
html of the descriptions files, but it is still possible.
Generally speaking I don't think it's a good idea to distribute an open source gallery that allows for any html
to be injected by default.
So my idea is:
Eventually if the last part seems outrageous to you, I could add a pref switch to allow filtered HTML
in the description files. That's more work and I personnaly don't care for it anyway (the ability to
have html and the work of writing the filter).
Of course some people's reaction will be that they don't want to learn one more syntax for entering comments.
This is not a valid nor acceptable argument.
Anyone who ever used a wiki would know it's must easier to write __bold__ and ''italics'' than
using <b>...</b> and <i>...</i>. The learning curve is a lot easier too.
Go modular.
It's been a while now that I want to redesign RIG using an OO approach, and in the process get a bunch of stuff
organized in a cleaner way. I'd like to introduce templates and other goodies without messing too much with the
current structure (which is just fine as is, but will get messy if I don't take care). Then I want a viewer system
to display either albums, images, videos, izumi files, archives, etc. And I want a comment system.
Later I'll want more stuff.
Rather than write a monolitic set of classes, which was my initial design, I wanted to introduce a notion of "viewer"
where a class would derive to provide viewing capabilities for say albums, images, etc. Now I realize the name for
that is a module.
Furthermore it's not only viewers that must be modular. Comments should be a module. Logging too, etc.
The idea is not to write the most generic modular system ever (is that even possible?) but to start with what I need
and provide room for further expansion later on.
This is still RIG, so the user basically naviguates one web page at a time, which has a header, a footer and a main viewer area.
To keep it simple a page has only one viewer. Typical viewer modules will be album (at large), image detail, video detail,
izumi detail or an archive file detail (zip mostly). Then extra module will add feature into the page: a naviguation
side bar, a comment detail at the bottom, template selection module in the options, access stats module output, etc.
Each module should rely on a core. The core will load modules, tell them what is happening, select the appropriate
viewer, tell modules to render, provide them with the necessary templates, handle option data and most important feed
the data files to the viewers and maintain the caches.
That was obvious, and even implied in the unwritten specs of RIG, especially the part that says there should be
viewers for each file type. I don't know how I missed that from the very beginning.
-- things I want in the future:
Also:
Todo:
Note that really the page template is not much different from the box template.
One just need to argue that a page is a big box.
RModuleManager => rig_mod_man
RModule (name, loader pattern)
RModLogin
RModQuery
RModAlbum (generic album content)
RModRigAlbum (folder with only rig files)
RModIzuDir (folder with only izu files)
RModPage
RModRigImage
RModIzuPage
RModZipPage
RModPageStat
RModAccessLog
RModCss
RModCache
RModOptions
RModStrings (provides i18n str:html_...)
RModComments
RModTemplate (aka the Template Manager)
RTemplate (name, parent module etc.)
RMediaInfo (query, web path, real path, cache path, option path)
RMediaDir (list/cache content)
RMediaFile
Of course I won't go to this extreme at first. The last one is my first bet.
Of course if a kind of user can add comments, it should be able to view them too.
But then I see no reason to prevent the rig admin from using illogical settings.
Maybe that's too much preferences for a single feature, I can start with a simpler mode:
Yeah that's a lot better.
I already see the problem here.
Given the comment on the Debian content negotiation page,
I'm not sure going for the strict rule is good.
Another idea would be to first find the exact match, then if it failed use the
approximate match. That would work as a reasonable heuristic, doing the perfect thing first
and then the humanly acceptable thing second.
It would be nice to also have some features not available currently in ZB:
First, there's a bunch of code which is already somewhat modularized:
The corresponding workflow is more or less this:
Negative points are:
Modules are loaded when needed or requested. For example a media module will be loaded depending on the kind of
media type being visited, typically by matching a regexp on query arguments.
In PHP simplified world, loading a module will simply mean including the PHP page. That means PHP will not parse unused
modules source code unless requested. In some other architecture (.Net f.ex.) the equivalent would be loading an assembly.
Initially, I wanted it the reverse way, namely the module handling an image album view would first compute its stuff and
then provide the rendering info to some template. This is not RIG actually works right now, and doing so had a number of
problem, the main one being responsiveness: from a web page perspective, it is important to start displaying stuff as
soon as possible and delay information retrieval to the last minute. That, in my opinion, enhances the user experience.
So the idea is that the template will be parsed and stuff that needs to be included will be computed as needed on the fly.
Ideally the template will use containers tags, something like [album:name] or [album:album-list].
The generaly syntax would be [module:name:[param=value]*]. The first time a module is referenced, it is loaded (if not
already available), and some method name is called with the required information (the current media info, the current
template, etc.) and the extra parameters. In return the method sends the HTML (either to the output or as a string, to be
determined) and more important sends back a flag indicating if the data should be cached (which implies a string is
returned). (Note: the idea is to avoid asking the module to compute twice the same container; in current RIG's template
design that doesn't happen often, except maybe for the prev/next links in image views; it may be more efficient to let the
module cache the info itself).
A media processing module would indicate which media it can handle and all modules that can handle the given media type
would be loaded and given a chance to operate (what if more than one module can handle the same type? To be determined).
That also means I got the prototype class hierarchy all wrong for RIG. Well that's what prototypes
are all about, so let's change it.
The merge should occur once the class hierarchy is in place. Don't hold your breath ;-)
This work is licensed by Raphaël Moll under a Creative Commons License.
Color Theme:
Gray
| Blue | Black
| Sand
| Khaki
| Egg
| None
2787 accesses, 1 access from 38.107.191.82
Visited 113 times by Google, last 2010/09/08 08:46
Visited 249 times by Yahoo!, last 2010/09/07 00:52
Visited 4 times by Alexa, last 2009/08/26 15:36
Visited 12 times by Teoma, last 2008/06/29 13:26
Visited 150 times by MSN, last 2010/09/07 00:14