Re: Service provider PSR: discussing the scope

[Alessandro Lai]

I'm very happy that this is gaining traction, thanks David for spinning 
this up!
Can I suggest you to focus on defining the scope of your proposal? In this 
way you could start gathering a sponsor and a working group, and start a 
PSR!

Reach out to me or one of the other secretaries if you need help or more 
details.

Il giorno domenica 4 marzo 2018 21:10:06 UTC+1, Matthieu Napoli ha scritto:
>
> Using the container for configuration is not (imho) the purpose of 
>> containers and makes it harder to standardize on using FQCN for container 
>> identifiers.
>
>
> I don't think it's limited to configuration. You'd have the same 
> (non-)issue with config-less containers.
>
> Matthieu
>  
>
>> On Sat, Mar 3, 2018, 15:18 Oscar Otero  wrote:
>>
>>> To me, the problem with these proposals is they have different 
>>> responsabilities in the same class. A ServiceProvider implementation 
>>> includes the callables to create instances of different services, defines 
>>> the key used to store each of these services and even include two methods: 
>>> one to get factories and other for extensions, so in many times you have to 
>>> create a method returning an empty array (see 
>>> https://github.com/container-interop/service-provider/issues/43), 
>>> (Interface segregation principle).
>>>
>>> I proposed a different approach (
>>> https://github.com/container-interop/service-provider/issues/45) 
>>> consisting in creating a factory for each service. The proposal is just a 
>>> sketch to illustrate the main concept (each object has just one 
>>> responsabiity: create a service) and surely can be improved.
>>>
>>>
>>>
>>> El 3 mar 2018, a las 14:07, David Négrier  
>>> escribió:
>>>
>>> To build upon Larry's answer, the container does not only contains 
>>> services. It knows how to build them.
>>>
>>> If we ended up "setting" in a container every service, well first... we 
>>> could use arrays instead of containers :) and then, the performance of the 
>>> container would degrade proportionally to the number of entries in the 
>>> container. You would have to instantiate and store every service on every 
>>> request, even if the service does not end up being called. So basically, 
>>> the bigest your application, the slowest.
>>>
>>> This is why both proposals carefully avoid the use of a "set" method.
>>>
>>> ++
>>> David.
>>>
>>>
>>> Le vendredi 2 mars 2018 23:02:49 UTC+1, Larry Garfield a écrit :

 The reason a simple set() won't work is that the "thing" put into the 
 container is generally not a value but instructions for how to produce 
 a value 
 on-demand, and the value is typically a service object.  How to encode 
 "here's 
 how to build the thing" is the main question to answer. 

 --Larry Garfield 

 On Friday, March 2, 2018 1:18:32 PM CST David Lundgren wrote: 
 > If the problem to solve is "what's a common way to put things in a 
 > container?" wouldn't the simplest solution be a `set($id, $value)` 
 method 
 > on the container? 
 > 
 > Most container implementations already have a method of this sort. 
 While a 
 > few have shared/concrete/protected concepts baked in, they could make
  
 > separate methods for changing it  based on the $id. 
 > 
 > Dave 
 > 
 > On Thursday, March 1, 2018 at 11:16:29 AM UTC-6, David Négrier wrote:
  
 > > Hey list, 
 > > 
 > > We are still in the process of forming a working group regarding a 
 Service 
 > > provider PSR. 
 > > 
 > > I've had the chance to speak about this with several Symfony 
 contributors, 
 > > and while discussing about this idea, Nicolas Grekas 
 > >  (from Symfony) came up with an
  
 > > alternative proposal. It's about having many containers working 
 together, 
 > > with a slightly different scope. First of all, I'd like to thank 
 Nicolas 
 > > for the time he is investing in researching this issue, and for all 
 the 
 > > feedback. We talked about his idea with Matthieu Napoli 
 > >  and Larry Garfield 
 > >  at the Paris ForumPHP in November. I'm 
 now 
 > > sharing this conversation with you. 
 > > 
 > > I put this in a blog article that you can find here: 
 > >
 https://thecodingmachine.io/psr-11-scope-of-universal-service-providers
  
 > > 
 > > I'm reposting the content of the article here, since it's directly 
 related 
 > > to PHP-FIG concerns. It's a bit long, but the topic is worth it :) 
 > > 
 > > Stated goal 
 > > 
 > > Each framework has it's own custom package format (bundles, 
 packages, 
 > > modules, etc...). What these package formats are doing is 
 essentially 
 > > always the same. They are used to put things in a container. 
 > > 

Re: Please make new pkgist release of PSR-16

[Alessandro Lai]

Hi Alice,
thanks for reminding us of this! I'll try to take care of this ASAP.

For reference, she's referring to this 
commit: 
https://github.com/php-fig/simple-cache/commit/408d5eafb83c57f6365a3ca330ff23aa4a5fa39b

Il giorno lunedì 5 marzo 2018 00:23:44 UTC+1, Alice Wonder ha scritto:
>
> When one uses
>
>"require": {
> "psr/simple-cache": "^1.0"
> }
>
> The result when using vimeo/psalm to check the code has errors because of 
> a bug in the 1.0.0 release that is fixed in master but not fixed in a 
> released version:
>
> expecting 'null|int|Psr\SimpleCache\DateInterval'
>
> The doc block bug is fixed in master but a stable release was never made 
> that contains the fix.
>
>   
>

-- 
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/d21bc98f-8ed6-4de6-991f-9a269fa1c7c0%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.

Please make new pkgist release of PSR-16

[Alice Wonder]

When one uses

   "require": {
"psr/simple-cache": "^1.0"
}

The result when using vimeo/psalm to check the code has errors because of a 
bug in the 1.0.0 release that is fixed in master but not fixed in a 
released version:

expecting 'null|int|Psr\SimpleCache\DateInterval'

The doc block bug is fixed in master but a stable release was never made 
that contains the fix.

  

-- 
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/bb39138a-00d4-43a3-91d5-915c9a2fb1aa%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: Service provider PSR: discussing the scope

[Matthieu Napoli]

>
> Using the container for configuration is not (imho) the purpose of 
> containers and makes it harder to standardize on using FQCN for container 
> identifiers.


I don't think it's limited to configuration. You'd have the same 
(non-)issue with config-less containers.

Matthieu
 

> On Sat, Mar 3, 2018, 15:18 Oscar Otero  
> wrote:
>
>> To me, the problem with these proposals is they have different 
>> responsabilities in the same class. A ServiceProvider implementation 
>> includes the callables to create instances of different services, defines 
>> the key used to store each of these services and even include two methods: 
>> one to get factories and other for extensions, so in many times you have to 
>> create a method returning an empty array (see 
>> https://github.com/container-interop/service-provider/issues/43), 
>> (Interface segregation principle).
>>
>> I proposed a different approach (
>> https://github.com/container-interop/service-provider/issues/45) 
>> consisting in creating a factory for each service. The proposal is just a 
>> sketch to illustrate the main concept (each object has just one 
>> responsabiity: create a service) and surely can be improved.
>>
>>
>>
>> El 3 mar 2018, a las 14:07, David Négrier > > escribió:
>>
>> To build upon Larry's answer, the container does not only contains 
>> services. It knows how to build them.
>>
>> If we ended up "setting" in a container every service, well first... we 
>> could use arrays instead of containers :) and then, the performance of the 
>> container would degrade proportionally to the number of entries in the 
>> container. You would have to instantiate and store every service on every 
>> request, even if the service does not end up being called. So basically, 
>> the bigest your application, the slowest.
>>
>> This is why both proposals carefully avoid the use of a "set" method.
>>
>> ++
>> David.
>>
>>
>> Le vendredi 2 mars 2018 23:02:49 UTC+1, Larry Garfield a écrit :
>>>
>>> The reason a simple set() won't work is that the "thing" put into the 
>>> container is generally not a value but instructions for how to produce a 
>>> value 
>>> on-demand, and the value is typically a service object.  How to encode 
>>> "here's 
>>> how to build the thing" is the main question to answer. 
>>>
>>> --Larry Garfield 
>>>
>>> On Friday, March 2, 2018 1:18:32 PM CST David Lundgren wrote: 
>>> > If the problem to solve is "what's a common way to put things in a 
>>> > container?" wouldn't the simplest solution be a `set($id, $value)` 
>>> method 
>>> > on the container? 
>>> > 
>>> > Most container implementations already have a method of this sort. 
>>> While a 
>>> > few have shared/concrete/protected concepts baked in, they could make 
>>> > separate methods for changing it  based on the $id. 
>>> > 
>>> > Dave 
>>> > 
>>> > On Thursday, March 1, 2018 at 11:16:29 AM UTC-6, David Négrier wrote: 
>>> > > Hey list, 
>>> > > 
>>> > > We are still in the process of forming a working group regarding a 
>>> Service 
>>> > > provider PSR. 
>>> > > 
>>> > > I've had the chance to speak about this with several Symfony 
>>> contributors, 
>>> > > and while discussing about this idea, Nicolas Grekas 
>>> > >  (from Symfony) came up with an 
>>> > > alternative proposal. It's about having many containers working 
>>> together, 
>>> > > with a slightly different scope. First of all, I'd like to thank 
>>> Nicolas 
>>> > > for the time he is investing in researching this issue, and for all 
>>> the 
>>> > > feedback. We talked about his idea with Matthieu Napoli 
>>> > >  and Larry Garfield 
>>> > >  at the Paris ForumPHP in November. I'm 
>>> now 
>>> > > sharing this conversation with you. 
>>> > > 
>>> > > I put this in a blog article that you can find here: 
>>> > >
>>> https://thecodingmachine.io/psr-11-scope-of-universal-service-providers 
>>> > > 
>>> > > I'm reposting the content of the article here, since it's directly 
>>> related 
>>> > > to PHP-FIG concerns. It's a bit long, but the topic is worth it :) 
>>> > > 
>>> > > Stated goal 
>>> > > 
>>> > > Each framework has it's own custom package format (bundles, packages,
>>>  
>>> > > modules, etc...). What these package formats are doing is essentially
>>>  
>>> > > always the same. They are used to put things in a container. 
>>> > > 
>>> > > If the PHP-FIG could come up with a unique package format that could 
>>> be 
>>> > > supported by all frameworks, package developers could truly write 
>>> classes 
>>> > > that can be used in any framework more easily. 
>>> > > 
>>> > > Hence, the stated goal of this PSR (let's call it PSR-X since it 
>>> does not 
>>> > > have a number yet) is to find a common way to *put things in a 
>>> container*. 
>>> > > 
>>> > > We (the container-interop group) have been working on this for quite 
>>> some 
>>> > > time and