> What we followed was just an array, no other format.

The point is, this requires server-side bootstrapping. I can't add a
new assets without also writing code, so already here you've created a
dependency on some sort of server-side global bootstrapping facility.
I am to keep things simpler than that.

> You follow symlink, we followed directly looking at filesystem and reading 
> the contents and serving as psr-7 Response .

Symlinks are optional - from the spec:

"This specification does not stipulate how this is implemented.
Examples include: proprietary web-server configuration files, e.g.
Apache, NGINX, or other web-server software, front controllers,
middleware, symbolic links created by installation scripts, or any
other means."

You can absolutely use the file-system and serve contents via PSR-7
response. (I don't plan to do that myself, as dispatching PHP just to
deliver a static asset is not necessary if all your static assets are
pre-baked and checked into source-control - we strictly view things
like compilation and serialization as design-time rather than run-time
tasks, which seems to make life easier for our front-end developers.
YMMV)


On Mon, Oct 17, 2016 at 4:04 PM, Hari K T <kthar...@gmail.com> wrote:
> Hi Rasmus,
>
> Trying to write inline, so I don't miss your question.
>
>> > 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.
>
>
> What we followed was just an array, no other format.
>
> [
>  'vendor/package/css/hello.css' => dirname(dirname(__DIR__)) .
> '/asset/css/test.css',
>  'vendor/package' => dirname(dirname(__DIR__)) . '/asset',
> ]
>
>>
>> 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.
>
>
> Symlink may be easy. I was not using symbolic link and the files were served
> via psr-7 response though. It lacks caching and stuffs like that for now.
>
>>
>> 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.
>
>
> Ya, the approaches choosen to serve the files is a bit different. You follow
> symlink, we followed directly looking at filesystem and reading the contents
> and serving as psr-7 Response .
>
>>
>> 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.
>
>
> I have no trouble with the length of the url. Not sure if someone else asked
> the same.
>
> --
> 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/CAESZFt%2BVK3ORC7pB-7iDd0j5-kZZ1TZ06ruoRmVzy5tswiy9Tg%40mail.gmail.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_iMvV9-azP1gbi-5Lefj-BEYwyRozg0oWpSpO%2BnrUD8dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to