File overhaul

[Tim K]

Hi guys,

wanted to suggest a change in the File API

the main goal is to make it easier to write custom file extensions through modules etc

therefore I'd suggest a registry pattern like

File::register_handler("pdf", "MyPDFFile", 50);

The first argument being the file "." extension, the second the classname and the third priority.
This way core filetypes can easily be added or overwritten...
When new files are created - File::get_file_handler(extension) would either return a new instance of the class with the highest priority or default back to File...

alternatively to the file extension - the mime type could be used to identify the content type...

What do you think?

[Uncle Cheese]

I love that idea!

Another suggestion:

Working locally on an existing site is a huge pain when it comes to
assets. The database is looking for files that are non-existent,
unless you've opted to download your client's entire assets folder. No
thanks.

It seems to me there could be a really simple change to the API to
make this better. Allow getFilename(), getURL(), and other accessors
to prepend an alternate BaseHref so that file paths would always point
to the web (say, your live site). In other words:

For file 'assets/my-folder/myfile.pdf"
$File.URL returns "http://www.mysite.com/assets/my-folder/myfile.pdf"
Instead of "http://localhost:8888/mysite/assets/my-folder/myfile.pdf"

Maybe there's a way to do this that is eluding me. I'm new to local
development, so bear with me.

[Mat Weir]

It would be nice too if the HTML editor used a similar pattern to internal hyperlinks, like [file id=2], or [image id=2], and then perhaps width, height and class parameters in there too, like [image id=2 width=80 height=60 class=left].

We've had clients who go to tidy up there Files & Images section, only to find that the CMS doesn't manage files moving around and their pages then have broken images.

Cheers,

Mat Weir

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[Tim Klein]

Good point!

There has been some discussion about versioning assets...
this should fit in nicely.

How would actual files be stored when versioned?

--
Tim Klein

address: Level 1, 1 Searle Lane, Queenstown
skype: kelptim
email: t...@kelpdesign.com
website: http://www.kelpdesign.com
phone: +64 3 409 2031
mobile: +64 21 234 35 78

---

Check out http://www.page-elements.com/

[Ingo Schommer]

Tim: Why doesn't decoration of the File class work for you,

rather than subclassing? BTW: When I first read the "handler" API suggestion I thought

it had something to do with HTTP request handling, so got a bit confused :)

Aaron: I think its just a matter of applying Director::$alternateBaseURL

consistently across all Director methods, and then using Director::baseURL()

consistently throughout the File and Folder APIs. Wanna go through

the methods and check they are in fact using it properly?

If not, please fix and write a unit test for it :) The File API might

look simple, but it gets quite complicated around file paths in the

DB vs. filesystem, so any change here has to be heavily tested.

---

Ingo Schommer | Senior Developer

SilverStripe

http://silverstripe.com

in...@silverstripe.com

Phone: +64 4 978 7330 x 42

Skype: chillu23

[Hamish Campbell]

On Feb 21, 6:50 am, Uncle Cheese <aaroncarl...@gmail.com> wrote:
> Working locally on an existing site is a huge pain when it comes to
> assets. The database is looking for files that are non-existent,
> unless you've opted to download your client's entire assets folder. No
> thanks.

Yeah we have this problem frequently as well. We usually export the
files table before doing any work then reloading it before pushing to
live, although this is certainly much less of a problem now that
AssetAdmin doesn't attempt to sync on every load.

Here's a thought - maybe a task to touch missing file paths so you can
work on a local database without worrying about the records
disappearing - useful for testing downloads etc too. Just a thought.

Hamish

[Sam Minnée]

Tim: Why doesn't decoration of the File class work for you,

rather than subclassing? BTW: When I first read the "handler" API suggestion I thought

it had something to do with HTTP request handling, so got a bit confused :)

I think that the idea of a registration API could be a good one - we don't need to resort to decorators for every single API design challenge.

However, the most important question hasn't yet been answered: what is the registered handler going to do?

[Tim Klein]

I like to think of decorating more of 'adding simple functionality' to
existing objects.
And yes, "handler" sounds a bit wrong ;) - how about
File::register_type(Extension, Object, Priority)?

This would work well for eg. adding a rotate function to Image

On file instances this could be much more specific:

Eg: a PDF::forTemplate could return a screenshot of the pdf file,
created using imagick
Sound files could be converted to other formats...
Video files could get screen grabs

Also the individual metadata could be extracted much more easily (play
time, page count, ....)

I guess nothing for the core to worry about - just nice if there was
an elegant way of handling this.

[Marcus Nyeholt]

My guess is something like the way an 'Image' type is created for files of an image mimetype?

 

However, the most important question hasn't yet been answered: what is the registered handler going to do?

--

[DesignCity]

We face it a fair amount too - an effective & easy solution would be
excellent.

Cheers,
Michael

[Ingo Schommer]

True, those are all good use cases, and something like forTemplate()

would be better subclassed rather than "augmented" by a decorator.

Sounds similar to the existing Object::use_custom_class(), just conditionally on extension. 

I assume that using dependency injection conditionally would be a bit over the top?

I've looked through core and various modules, invocations of "new File()" are very rare and easy to replace,

99% of the time they're created through the Upload class.

[Uncle Cheese]

The problem with setBaseURL() is that it has effects far beyond the
File API. Suddenly all my $Link calls on SiteTree objects get
prepended with my alternate URL, because Link() uses
Director::baseURL();

> > Check outhttp://www.page-elements.com/

>
> > --
> > You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
> > To post to this group, send email to silverst...@googlegroups.com.
> > To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/silverstripe-dev?hl=en.

>
> ---
> Ingo Schommer | Senior Developer
> SilverStripehttp://silverstripe.com

> i...@silverstripe.com

[Brice Burgess]

Perhaps this may be an opportunity to build generalized CDN/Edge Server
support into File objects as an [inadvertent] solution to this? Instead
of explicitly setting alternative BaseURLs, maybe the File object could
have fallback support of "Asset Repositories"?

The Asset Repositories would simply be locations containing a potential
mirror of the assets directory. The Administrator would define this in a
_config, giving each a priority. These definitions should support at
least filesystem lookups as well as HTTP/HTTPS, with the default being
the local asset directory in the filesystem.

It would be interesting to have priorities per filetype too. This would
allow, for instance, all calls to video files(FLV/MP4/etc) to first try
the "Remote Video Server A" repository before falling back to the local
asset directory.

So the File object would essentially test for the existence of a file at
a repository in accordance to priority, and either return it, fallback
to the next repository, or return a 404 exhausted. Each test could be
cached for performance.

Would this also resolve the issue at hand? Is it of any interest?

~ Brice

[Dan Rye]

+1 Brice.

[Tim Klein]

Hi Brice,

yeah sounds awesome.

I have been thinking about having a remote assets folder too...

Any experience with this?

cheers

[Uncle Cheese]

There are a couple ways to have "remote" assets. The Uploadify module
plugs in to Amazon S3 which will give you remote storage, but you lose
a lot of the file manipulation functionality in Silverstripe, e.g.
image sizing. You can also set up your assets folder as an NFS mount
for sharing of assets between sites. That works pretty well.

On Feb 24, 9:23 am, Tim Klein <t...@kelpdesign.com> wrote:
> Hi Brice,
>
> yeah sounds awesome.
>
> I have been thinking about having a remote assets folder too...
>
> Any experience with this?
>
> cheers
>
>
>
>
>
> On Thu, Feb 24, 2011 at 4:40 AM, Dan Rye <dan....@gmail.com> wrote:
> > +1 Brice.