On 6/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
On 6/7/07, Richard Frovarp <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > On 5/31/07, Andreas Hartmann <[EMAIL PROTECTED]> wrote: > >> Richard Frovarp schrieb: > >> > Is there a way to call a page via it's UUID from a browser? My > >> issue is > >> > that we translate from UUIDs to URLs when a page is being edited. > >> > > This feature was implemented in 1.3. The design used one protocol > > (cleverly named "content:") for access to all documents and resources. > > The protocol finds the resource by testing a variety of formats > > including the UUID. (UUIDs are strictly formatted UNIDs.) See the > > second half of 13HELP for the specs: > > http://svn.apache.org/repos/asf/lenya/branches/revolution/1.3.x/13HELP.txt > > > > > > XMAPs can just pass the resource identifier portion of the URL to the > > protocol and retrieve the correct resource. That avoids issues about > > needing a special prefix. The protocol works fine internally so no > > other code cares whether the identifier is a path or UNID. > > > > Links should always be stored as UNIDs. Editors must translate > > path-based identifiers to UNIDs before storing documents. The "Add > > link" and "Add image" functions should display resource titles to hide > > UNIDs from users. > > > > solprovider > > There is a protocol in 1.4, lenya-document. I want to use HTTP(S) and > provide the UUID. Upon save, the path-based identifiers are converted to > UUIDs for storage. Links really don't matter too much as they are links > and render properly if their URL is of the lenya-document protocol. > Images however, currently have to be translated from UUID to path-based > when the page is loaded into the editor, so that they display. When > saved out they are converted back to UUID. The problem here is if the > image is moved (or anything referenced by a path inside of Lenya) while > a page referencing it is being edited, the reference could be lost. This > is what I hope to prevent from happening. > > How do you handle displaying images in the editors? > > RichardI was working on integrating an editor when I went on sabbatical. I was hacking Kupu and finally realized Kupu was not designed for flexibility. I will return to the 1.3 in mid-August and integrating an editor is the highest priority. Importing a new image from the editor creates a new resource and places an <img src="/pub/unid.ext"/> in the document. That is translated to <LLINK TAG="img" UNID="unid" {other atributes}/> upon saving. Other links are handeled similarly: <LLINK TAG="a" UNID="unid" {other atributes}/> These tags are translated back to a browser-readable path when retrieving the document for any purpose. 1.3 distinguishes between three basic resource types: XML, text, and binary. XML resources are usually called documents. Text resources will allow browser editing of CSS, JS, and other configuration files. (1.3.1 will move almost everything into the datastore.) Binary resources can only be displayed (at least with the current plans.) Extensions are handled so a binary resource named "logo" can easily be changed from a GIF to a JPG to a PNG without updating any documents. I return to developing Lenya in August. I do not want to continue with Kupu. We used Fckeditor at my job, and it should work. Is there a list of Apache-approved editors?
By "Apache-approved" do you mean compatible with the Apache license? kupu and bxe are the only ones I know of. FCKeditor and TinyMCE are both unfortunately LGPL (although the latter will apparently re-license for a fee -- http://wiki.moxiecode.com/index.php/TinyMCE:FAQ#I_don.27t_like_LGPL.2C_is_there_a_commercial_license_available_for_me.3F). I've looked pretty hard and haven't found anything else of quality that is cross-browser compatible and Apache-license-compatible. Maybe FCKeditor or TinyMCE will eventually adopt GPLv3 (http://uk.news.yahoo.com/cwire/20070605/ttc-fsf-announces-gpl-apache-license-com-78e70a2.html) and then we can possibly consider bundling one with Lenya.
solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
