Re: Integration of JS and CSS

[Alice Wonder]

 Okay I have a better expression of what I have in mind, I don't think I 
communicated it well before, my mind works differently than most and that 
results in communication problems, I am sorry.

https://github.com/AliceWonderMiscreations/ResourceManager

That's a github where I am starting to flesh it out.

The basic concept is described there, I could retype it here but the Google 
Groups interface is hard for me to use, it does weird things, markdown is 
so much easier and github supports markdown.

What is there is a synopsis of what I am looking for that I believe would 
be of huge benefit to web application development as well as improve 
security by doing things like automatically generating integrity attribute 
etc. when checksum exists in the script configuration file.

With respect to NPM etc. I have used them and do not like them. Similar 
issues I have with Composer.

I think Composer is fantastic for development but I do not believe it is 
safe for deployment because it really is no different than static linking 
resulting in vulnerable code. Also there is very little oversight over what 
goes into packagist.

If I was a blackhat I would create Class A and then Class B that depends on 
A and then C that depends on B and then very useful D that depends on C.

Once D had sufficient install base, I just need to put my trojan in A and 
then soon the trojan would be deployed all over the world. It would be 
found eventually, but it is too easy to do, hence why I do not like 
Composer for deployment.

I don't mean to offend anyone, it's a fantastic tool for development.

The JavaScript managers have same issue and indeed it has happened with 
them before.

-- 
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/5c82418d-b739-478e-bc9a-ebb981370d13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Integration of JS and CSS

[Alessandro Lai]

Hi Alice, and welcome to this mailing list.

I'm sorry but I think you misread the previous response: we're not talking 
about RPM, but NPM, and Yarn. They are JS-specific package managers, that 
are designed to resolve exactly what you need. You should also take a look 
at Symfony WebPack Encore, that would solve even better your needs, with a 
nice packing of CSS and JS 
together: https://symfony.com/doc/current/frontend.html

Il giorno lunedì 5 marzo 2018 01:07:33 UTC+1, Alice Wonder ha scritto:
>
> What I am going to do is create a reference implementation for a class 
> that adds JavaScript and CSS to a document that will allow third party 
> JS/CSS to be packaged separately.
>
> My reference class itself will not be of benefit to 99% of the world 
> because it will use DOMDocument but from it, hopefully it will demonstrate 
> what a standard interface could be like, and then if such as PSR is ever 
> standardized I could then port the reference class to actually implement 
> what is agreed upon.
>
> Bundling 3rd part JS/CSS into an app for production deployment though is 
> just fundamentally wrong IMHO and right now that's what has to be done for 
> both composer and RPM installs.
>
> On Sunday, March 4, 2018 at 3:13:24 PM UTC-8, Alice Wonder wrote:
>>
>> Yes I am extremely familiar with RPM and have been packaging RPMs since 
>> the Red Hat 6.0 days (pre Fedora)
>>
>> But they don't address this issue. For example, the RPMs that exist for 
>> roundcube mail include jQuery and other 3rd party JS in the roundcube RPM 
>> itself because their is no standard way to for roundcube to say it needs 
>> jQuery X.
>>
>> PHP class dependencies can be in separate packages thanks to autoloaders, 
>> but not the JavaScript
>>
>> On Thursday, March 1, 2018 at 5:29:39 PM UTC-8, Alice Wonder wrote:
>>>
>>> Hello,
>>>
>>> I have a php class that generates an HTML5 audio player with support for 
>>> WebVTT captions and chapters and is very accessible.
>>>
>>> It's a personal class, I am not distributing it as FLOSS and I probably 
>>> won't, but it uses jQuery and its own JavaScript and it's own CSS (in an 
>>> external file, I do not allow the style attribute in my code) and its own 
>>> webfont that is used kind of like an image sprite but better IMHO than 
>>> using an image sprite (for the interface buttons).
>>>
>>> Anyway one of the things that literally bothers me about so many web 
>>> applications is they bundle scripts many of which (e.g. jQuery) are third 
>>> party to the web application.
>>>
>>> I was thinking it would be good for something *like* PSR-4 to exist for 
>>> non-php resources.
>>>
>>> What I mean is Web Application A requires jQuery >= 3 but doesn't need 
>>> to bundle it itself, where the bundled often often becomes stale.
>>>
>>> Instead there could be a PSR class interface defined so that when the 
>>> web application needs to add jQuery to the (x)html document head - it could 
>>> call
>>>
>>> $whatever::addJavaScript("jQuery:jQuery", "3.0");
>>>
>>> Class $whatever would then look in virtual vendor namespace "jQuery" for 
>>> a script that meets the name definition of "jQuery" with minimum version 
>>> "3.0" and returns the appropriate URI to add to the script node.
>>>
>>> For people who use composer it may not make much difference, they will 
>>> end up with stale version over time (or initially if a composer.lock file 
>>> is used) just like they often end up with stale unpatched vulnerable 
>>> versions of class libraries - but for those who actually update their 
>>> installs periodically (or use an actual package manager which composer is 
>>> not) it could be of a great benefit.
>>>
>>> I already do something similar for my own private web apps, it could 
>>> IMHO be a huge benefit if there was a standardized way of doing it.
>>>
>>> Thoughts?
>>>
>>

-- 
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/a421a13d-3646-4f5c-8235-8fdd6c73d02d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Integration of JS and CSS

[Alice Wonder]

What I am going to do is create a reference implementation for a class that 
adds JavaScript and CSS to a document that will allow third party JS/CSS to 
be packaged separately.

My reference class itself will not be of benefit to 99% of the world 
because it will use DOMDocument but from it, hopefully it will demonstrate 
what a standard interface could be like, and then if such as PSR is ever 
standardized I could then port the reference class to actually implement 
what is agreed upon.

Bundling 3rd part JS/CSS into an app for production deployment though is 
just fundamentally wrong IMHO and right now that's what has to be done for 
both composer and RPM installs.

On Sunday, March 4, 2018 at 3:13:24 PM UTC-8, Alice Wonder wrote:
>
> Yes I am extremely familiar with RPM and have been packaging RPMs since 
> the Red Hat 6.0 days (pre Fedora)
>
> But they don't address this issue. For example, the RPMs that exist for 
> roundcube mail include jQuery and other 3rd party JS in the roundcube RPM 
> itself because their is no standard way to for roundcube to say it needs 
> jQuery X.
>
> PHP class dependencies can be in separate packages thanks to autoloaders, 
> but not the JavaScript
>
> On Thursday, March 1, 2018 at 5:29:39 PM UTC-8, Alice Wonder wrote:
>>
>> Hello,
>>
>> I have a php class that generates an HTML5 audio player with support for 
>> WebVTT captions and chapters and is very accessible.
>>
>> It's a personal class, I am not distributing it as FLOSS and I probably 
>> won't, but it uses jQuery and its own JavaScript and it's own CSS (in an 
>> external file, I do not allow the style attribute in my code) and its own 
>> webfont that is used kind of like an image sprite but better IMHO than 
>> using an image sprite (for the interface buttons).
>>
>> Anyway one of the things that literally bothers me about so many web 
>> applications is they bundle scripts many of which (e.g. jQuery) are third 
>> party to the web application.
>>
>> I was thinking it would be good for something *like* PSR-4 to exist for 
>> non-php resources.
>>
>> What I mean is Web Application A requires jQuery >= 3 but doesn't need to 
>> bundle it itself, where the bundled often often becomes stale.
>>
>> Instead there could be a PSR class interface defined so that when the web 
>> application needs to add jQuery to the (x)html document head - it could call
>>
>> $whatever::addJavaScript("jQuery:jQuery", "3.0");
>>
>> Class $whatever would then look in virtual vendor namespace "jQuery" for 
>> a script that meets the name definition of "jQuery" with minimum version 
>> "3.0" and returns the appropriate URI to add to the script node.
>>
>> For people who use composer it may not make much difference, they will 
>> end up with stale version over time (or initially if a composer.lock file 
>> is used) just like they often end up with stale unpatched vulnerable 
>> versions of class libraries - but for those who actually update their 
>> installs periodically (or use an actual package manager which composer is 
>> not) it could be of a great benefit.
>>
>> I already do something similar for my own private web apps, it could IMHO 
>> be a huge benefit if there was a standardized way of doing it.
>>
>> Thoughts?
>>
>

-- 
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/182782bb-bb29-4a54-8a39-e2972a235d44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Integration of JS and CSS

[Alice Wonder]

Yes I am extremely familiar with RPM and have been packaging RPMs since the 
Red Hat 6.0 days (pre Fedora)

But they don't address this issue. For example, the RPMs that exist for 
roundcube mail include jQuery and other 3rd party JS in the roundcube RPM 
itself because their is no standard way to for roundcube to say it needs 
jQuery X.

PHP class dependencies can be in separate packages thanks to autoloaders, 
but not the JavaScript

On Thursday, March 1, 2018 at 5:29:39 PM UTC-8, Alice Wonder wrote:
>
> Hello,
>
> I have a php class that generates an HTML5 audio player with support for 
> WebVTT captions and chapters and is very accessible.
>
> It's a personal class, I am not distributing it as FLOSS and I probably 
> won't, but it uses jQuery and its own JavaScript and it's own CSS (in an 
> external file, I do not allow the style attribute in my code) and its own 
> webfont that is used kind of like an image sprite but better IMHO than 
> using an image sprite (for the interface buttons).
>
> Anyway one of the things that literally bothers me about so many web 
> applications is they bundle scripts many of which (e.g. jQuery) are third 
> party to the web application.
>
> I was thinking it would be good for something *like* PSR-4 to exist for 
> non-php resources.
>
> What I mean is Web Application A requires jQuery >= 3 but doesn't need to 
> bundle it itself, where the bundled often often becomes stale.
>
> Instead there could be a PSR class interface defined so that when the web 
> application needs to add jQuery to the (x)html document head - it could call
>
> $whatever::addJavaScript("jQuery:jQuery", "3.0");
>
> Class $whatever would then look in virtual vendor namespace "jQuery" for a 
> script that meets the name definition of "jQuery" with minimum version 
> "3.0" and returns the appropriate URI to add to the script node.
>
> For people who use composer it may not make much difference, they will end 
> up with stale version over time (or initially if a composer.lock file is 
> used) just like they often end up with stale unpatched vulnerable versions 
> of class libraries - but for those who actually update their installs 
> periodically (or use an actual package manager which composer is not) it 
> could be of a great benefit.
>
> I already do something similar for my own private web apps, it could IMHO 
> be a huge benefit if there was a standardized way of doing it.
>
> Thoughts?
>

-- 
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/212bd45f-816d-4287-a79c-5d6735fe1427%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Integration of JS and CSS

[Steve Winter]

Hello Alice

Are you familiar with the likes of npm (node package manager - 
https://www.npmjs.com/ ) or yarn (which is another 
(mostly) JavaScript package manager - https://yarnpkg.com/en/ 
)?

They work in much the same way as composer does, in that you can add (require) 
packages, and save those to a package.json file which records the package and 
the version which you have installed. In much the same way as you can do 
composer install, you can also do yarn install, which will read package.json, 
install all of the dependencies, and then create a yarn.lock file (same purpose 
as composer.lock).

You can then use those assts directly, or there are then tools like web pack 
(https://webpack.js.org/ ) which you can use to 
‘compile’ those into ‘bundled' assets for deployment in your solution.

>From what I can gather from your ‘wish’ below it’s likely that these existing 
>‘front end’ dependency managers will cover what you’re trying to achieve.

Hope this helps
Steve



> Hello,
> 
> I have a php class that generates an HTML5 audio player with support for 
> WebVTT captions and chapters and is very accessible.
> 
> It's a personal class, I am not distributing it as FLOSS and I probably 
> won't, but it uses jQuery and its own JavaScript and it's own CSS (in an 
> external file, I do not allow the style attribute in my code) and its own 
> webfont that is used kind of like an image sprite but better IMHO than using 
> an image sprite (for the interface buttons).
> 
> Anyway one of the things that literally bothers me about so many web 
> applications is they bundle scripts many of which (e.g. jQuery) are third 
> party to the web application.
> 
> I was thinking it would be good for something *like* PSR-4 to exist for 
> non-php resources.
> 
> What I mean is Web Application A requires jQuery >= 3 but doesn't need to 
> bundle it itself, where the bundled often often becomes stale.
> 
> Instead there could be a PSR class interface defined so that when the web 
> application needs to add jQuery to the (x)html document head - it could call
> 
> $whatever::addJavaScript("jQuery:jQuery", "3.0");
> 
> Class $whatever would then look in virtual vendor namespace "jQuery" for a 
> script that meets the name definition of "jQuery" with minimum version "3.0" 
> and returns the appropriate URI to add to the script node.
> 
> For people who use composer it may not make much difference, they will end up 
> with stale version over time (or initially if a composer.lock file is used) 
> just like they often end up with stale unpatched vulnerable versions of class 
> libraries - but for those who actually update their installs periodically (or 
> use an actual package manager which composer is not) it could be of a great 
> benefit.
> 
> I already do something similar for my own private web apps, it could IMHO be 
> a huge benefit if there was a standardized way of doing it.
> 
> Thoughts?
> 
> -- 
> 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/7c6c34a4-9bfc-4742-8bea-3a5a257e7eb5%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/D3C6E186-963D-4798-B22B-D1BAAE0C943C%40msdev.co.uk.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME cryptographic signature