Re: Google Gears is out
Justizin <justizin@...> wrote:
> We'll need a much richer AJAX interface before we can pretend to use
> something like this with any level of triviality. Let me know when
> Plone3 returns to moving in the direction of asynchronous content view
> loading.
>
I'm sorry, but I disagree completely with that. However it is probably
just down to a different idea of what an offline Plone would look like,
so I'll describe how I think such a beast might work.
There are at least two basic use scenarios:
The simple(?) one is letting people select part of the Plone site to be
browsable offline. That ought to be fairly straightforward within gears.
There should be some browsable view where you can select pages or
complete folders to be available offline, and some mechanism (i.e.
another screen) for telling gears to go and synchronise (in the
background) the offline content with the current site.
When browsing offline the skin probably wants a few changes which I
expect could be done by substituting some of the css and maybe
javascript. For example a lot of actions in the standard skin would
simply be hidden and you wouldn't want any AJAX functionality since you
won't have a server with which to interact. Otherwise it's a glorified
cache.
The harder one is editing offline. For that I would discard the Plone
skin entirely. Gears gives you a sql database, so the initial setup
would download your content schemata and set up tables based to store
fields for each content type. I'd use the same screens I suggested above
to select parts of the site to be made available offline to let you
specify which areas you want to be able to edit. I'd imagine you would
select at most a very small section to be editable and a more of the
site to be browsable.
The edit screen I imagine to be a very simple table layout of titles and
fields but preferably with a click-to-edit interface rather than a form.
You'ld have a limited set of widgets, and I'd imagine that not all
fields would be editable offline: e.g. a picklist where the vocabulary
was generated dynamically wouldn't be editable, but one with a static
vocabulary would. Probably non-editable fields would store a local copy
of the displayed value but not let you edit it.
There would probably also be limitations on which content types could be
handled offline: I expect that any complex content types would require
custom handling.
When a field is edited the new value is saved in the local database (but
the downloaded value has to be kept also). You wouldn't be able to see
your edits in the Plone skin (viewing the page would show you the
original version but with a warning message on the page saying that it
is out of date).
New content could also be created offline in the same way: a very plain
interface based on the schema
When you go online, your edits would be uploaded. There has to be some
scheme to handle conflicts: either the Lotus Notes way of creating a
duplicate content object marked as a conflict, or a 3-way merge with
conflicts flagged. The synchronisation screen would show you conflicted
pages and give you some means to resolve the conflicts.
In summary, Plone (or a Plone product) would need to grow a mechanism
for delivering the content as fields and for synchronising changes, but
the simpler and less scripting there is in the Plone UI the easier
something like this would be.
On a slightly different note, I'm wondering whether kupu (a future
version, not kupu 1.4) can leverage Gears (with simple and clean
degradation for users who don't have Gears installed).
I haven't checked yet whether the file capture functions let you bypass
the need for a server roundtrip to get at file contents, but if it does
them it may be possible to offer an 'insert file' button to insert html
off the local disc. 'insert image' could let you select a local image
also without having to think of it as a separate 'upload' stage. That
might require some changes server-side: it would be nice to have a
general mechanism where you could upload images or files simply by
adding some fields to an ordinary edit-form submission and have the
content type decide whether to store them internally (if it is a
composite document type), or externally (for ordinary pages).
Other things kupu might do if Gears is present could include regular
local saves, and possibly a non-broken undo/redo. Then if IE were to
crash the next time you visited the page you could be offered recovery
of your edits.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
RSS Feed