I think once I get action_cache working 1 & 2 will be a non-issue - if
the assets are stored seperately and then cached efficiently you'll get
the same performance and also not have the problem of page movement
interfering.
For 3, I'm not really sure I see the need. In my extension, you can get
a parent's asset by wrapping the <r:attachment> call in an <r:parent> -
I don't really understand why searching up the tree is necessary. But
this is just a couple of lines in the tags file, so I don't see it as a
major difference. Can you give me an example of when you'd want this?
acts_as_attachment is fine, but interferes with trying to do 1 & 2.
Also, the image manipulations provided are fairly rudimentary - how easy
is it for other extensions to specify their preferred image
manipulations (for example, all images for articles need to be resized
to by 200x200 and also need to be thumbnailed at 50x50?)
5 & 6 - I guess that's just a difference in interface design - I think
the popup guides the user better, but if that was the only point of
difference it would be easy enough to extend the extension with an extra
interface modification extension (well, once the view load order problem
is fixed anyway).
I'd really like us to get a unified data model going - I'll try and get
work done with action_cache this week - it should be just as efficient
as the acts_as_attachment method (well not quite as efficient, but
little enough difference to matter), and it really does give us a lot
more scope with what the extension can do.
Dan.
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sean Cribbs
Sent: Tuesday, 23 January 2007 1:42 AM
To: [email protected]
Subject: Re: [Radiant] [ANN] Page attachments extension
Daniel,
While they seem to tackle the same problem, I think our
extensions have very different philosophies and can thus probably live
separate lives. Here's some of the design decisions I made:
1) Uploaded files should live in the filesystem where the web
server can serve them efficiently to the client.
2) Although logically it would be nice to have uploaded files
live in a directory structure related to the page, page urls/slugs can
change more easily than files can be moved. Thus it's probably better
that the storage location of files be orthogonal to the page layout.
3) Pages should be able to easily access the assets/files
belonging to their parent(s). So, in-page tags that reference an asset
also search through the parent pages until it is found.
4) acts_as_attachment has worked well for me in the past, so
I'll use that for handling the uploads and file management.
5) The UI should mimic John's original comps as closely as
possible.
6) John liked the way Basecamp allowed you to do multiple
uploads (without a popup), so let's do that similarly.
I hope this reveals to you why I did certain things and not
other things. I'll continue to look through your code to see if there's
anything I can learn that might enhance page_attachments.
Sean
_______________________________________________
Radiant mailing list
Post: [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
