> Have you had a look at it? Any reason not to use Puli?

I have looked at it, and decided not to use it.

I had it in mind though, and I believe it could supported a standard
like this one, as an option, if they wanted to. (?)

It's no that there is anything wrong with it, per se - if what you
want is an asset management framework.

I don't though. I want something simple - something that doesn't marry
you to one vendor. A pattern that different vendors can implement very
easily, or even simple enough that a project can simply implement and
follow the pattern without using any library.

I just added a "meta" section to the document, it discusses some of
the reasons for keeping this simple:

https://gist.github.com/mindplay-dk/90507eb164e74bac7bbbf9abc97a04ee#meta

> how do you plan to work with more complex "asset pipes" like minifying / 
> concatenating / compiling LESS/SASS files...?

Good question, I should discuss this in the meta section.

The short answer is, it's out of scope of this standard.

I had it in mind, of course - but basically any complex build system,
ranging from a compiler, up to complex pipelines with Grunt, WebPack,
and other build tools, ultimately result in a compiled, static asset.

In a sense, your SASS files aren't static assets - they require some
tools for processing, compilation, minification, etc.

The output of those tools are static assets.

So this standard deals with the delivery of the compiled, static assets only.


On Mon, Oct 17, 2016 at 10:26 AM, David Négrier <david.negr...@gmail.com> wrote:
> Hey Rasmus,
>
> Interesting!
> I have a few questions. It seems you are looking to keep the spec as simple
> as possible. But how do you plan to work with more complex "asset pipes"
> like minifying / concatenating / compiling LESS/SASS files...?
>
> Also, @webmozart tackled the same problem in a very different way with Puli
> (http://docs.puli.io/en/latest/).
>
> Have you had a look at it? Any reason not to use Puli?
>
> ++
> David.
>
>
>
>
> Le lundi 17 octobre 2016 09:12:47 UTC+2, Rasmus Schultz a écrit :
>>
>> > Why do you want the folder name to be named assets itself ?
>>
>> The folder has to have a name - "assets" seemed like the logical choice.
>>
>> Perhaps what you're really wondering is, why a single folder and not a
>> map like in the Aura library?
>>
>> Because it's simpler. A map would require more than a standard - it
>> would require at least a configuration file format specification,
>> and/or possible a library or interfaces.
>>
>> Also, because we learned from doing something similar at work, that
>> being able to symlink vendored asset folders into the project's public
>> asset folder is really useful - it enables you to run an installation
>> script once, and the continue to add more files to the vendor
>> packages, since every file in the symlinked folder becomes
>> automatically available.
>>
>> Another reason is that a map cannot be interpreted or resolved at
>> design-time, by the browser - things like source-maps of relative
>> paths fall apart, since the relative public URLs do not map directly
>> to physical files. This is perhaps the main reason we came up with
>> this approach - anything else has proven to be highly impractical to
>> work with. Having to run a build or deploy script between every change
>> is cumbersome.
>>
>> Finally, the length or appearance of asset URLs is typically
>> completely irrelevant - about as irrelevant as the physical
>> file-system structure is to Composer packages. For the most part, no
>> person will ever see the URL of your CSS or JS files - wanting shorter
>> or neater URLs is purely vanity, it has no practical consequence.
>> Having a simple, predictable URL structure that prevents collissions,
>> is much more valuable than having pretty URLs.
>>
>> Good question though, thanks for reviewing this :-)
>>
>>
>> On Mon, Oct 17, 2016 at 3:00 AM, Hari K T <ktha...@gmail.com> wrote:
>> > Thank you Rasmus Schultz for the nice write up.
>> >
>> > After looking at it I think, it was something similar to what we had for
>> > Aura  https://github.com/friendsofaura/Aura.Asset_Bundle .
>> >
>> > I recently added psr-7 support : https://github.com/harikt/psr7-asset (
>> > Not
>> > saying it is perfect )
>> >
>> > I like some of the good things you mentioned towards the end of "A
>> > component
>> > responsible for the delivery of vendor-supplied assets:"
>> >
>> >
>> > https://gist.github.com/mindplay-dk/90507eb164e74bac7bbbf9abc97a04ee#12-asset-url-scheme
>> >
>> > Also I have question :
>> >
>> > Why do you want the folder name to be named assets itself ? ( But I do
>> > agree
>> > it is good to have a folder not to expose other files ;-) )
>> >
>> > What Aura.Asset_Bundle was using was mapping the folder with the package
>> > path. So it don't necessary to be in vendor folder you mentioned. It
>> > gives
>> > flexibility for the users to choose the path for their vendor specific
>> > css.
>> >
>> > Eg : In our case you can alter the css / js behaviours of the vendor/a/b
>> > with your own if you are mapping to /web/project-specific-assets .
>> >
>> > I do understand it needs some configuration though.
>> >
>> > And thanks for bringing this up, and it will be nice feature to have for
>> > considering psr-7, psr-15 etc.
>> >
>> > Thank you
>> >
>> > Hari K T
>> >
>> > You can ring me : +91 9388 75 8821
>> >
>> > http://harikt.com , https://github.com/harikt ,
>> > http://www.linkedin.com/in/harikt , http://www.xing.com/profile/Hari_KT
>> >
>> > Skype  : kthari85
>> > Twitter : harikt
>> >
>> > On Mon, Oct 17, 2016 at 3:10 AM, Rasmus Schultz <ras...@mindplay.dk>
>> > wrote:
>> >>
>> >> The webroot folder can have any name - a folder needs to be designated,
>> >> I
>> >> thought the spec was pretty clear on this point? :-)
>> >>
>> >>
>> >> On Oct 16, 2016 23:00, "Christopher Pitt" <cgp...@gmail.com> wrote:
>> >>>
>> >>> Nice write-up. Do you think it would be possible to survey member
>> >>> projects (including recently departed projects, like Laravel), to
>> >>> determine
>> >>> things like the most common/preferred name for the webroot folder?
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to a topic in the
>> >>> Google Groups "PHP Framework Interoperability Group" group.
>> >>> To unsubscribe from this topic, visit
>> >>> https://groups.google.com/d/topic/php-fig/f4qtsS54mVY/unsubscribe.
>> >>> To unsubscribe from this group and all its topics, send an email to
>> >>> php-fig+u...@googlegroups.com.
>> >>> To post to this group, send email to php...@googlegroups.com.
>> >>> To view this discussion on the web visit
>> >>>
>> >>> https://groups.google.com/d/msgid/php-fig/ad00f8f7-74f3-4a00-99aa-8b0909df7fa9%40googlegroups.com.
>> >>> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> >> Groups
>> >> "PHP Framework Interoperability Group" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> >> an
>> >> email to php-fig+u...@googlegroups.com.
>> >> To post to this group, send email to php...@googlegroups.com.
>> >> To view this discussion on the web visit
>> >>
>> >> https://groups.google.com/d/msgid/php-fig/CADqTB_gt7%2BjPbRKUZ88-m%2Be3N1OanuC%3DOiMj2QNZ%3DfkqjtmDqg%40mail.gmail.com.
>> >>
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>> > --
>> > You received this message because you are subscribed to a topic in the
>> > Google Groups "PHP Framework Interoperability Group" group.
>> > To unsubscribe from this topic, visit
>> > https://groups.google.com/d/topic/php-fig/f4qtsS54mVY/unsubscribe.
>> > To unsubscribe from this group and all its topics, send an email to
>> > php-fig+u...@googlegroups.com.
>> > To post to this group, send email to php...@googlegroups.com.
>> > To view this discussion on the web visit
>> >
>> > https://groups.google.com/d/msgid/php-fig/CAESZFtK_vrVRKEVFHBENU2hdFxGEc8P%2Bk4HL2m2F3sB2PHRymg%40mail.gmail.com.
>> >
>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/php-fig/f4qtsS54mVY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/0b271ca0-589b-4cfb-8c8b-61e080f1847a%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CADqTB_iiogHg%2BcFyPZWLpmPvZA40wSchHVbLBZoHbDkdM47P3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to