Weekly Status Update and IRC Meeting!

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Weekly Status Update and IRC Meeting!

weierophinney
Administrator
I've just posted a weekly status update:

 * http://framework.zend.com/zf2/blog/entry/2011-08-30-Dev-status-update

Also, a reminder: the IRC meeting is TOMORROW!!!!!

Current agenda is here (I seeded it because nobody else had):

 * http://framework.zend.com/wiki/display/ZFDEV2/2011-08-31+Meeting+Agenda

Please read, update, vote, etc.

Talk to you all tomorrow!

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Weekly Status Update and IRC Meeting!

DeNix
In my opinion both questions: modules and zf2 distribution lead to one
question worth discussing at IRC meeting:

What ZF2 ecosystem will look like?

based on discussions @ ML I have this picture in mind:

-- level 1: ZF
MVC/component framework distributed and maintained by Zend team
standard distro: Core + MVC
extended distro: Core + MVC + Extras

-- level 2: Community repo
Resembles ZF structure but each component(or extension to the standard
ZF class) is maintained by its author.
No CLA requirements. Possibly some CR team involvment.
All vendor's classes are under vendor specfic namespace.
One scenario for community repo is classes that extend ZF functionality,
so I one will be able to create something like MyLib/Http/Client
(extends Zend\Http\Client) with extra features
Another scenario is an early adoption/preview of proposals. So one could
show his proposal as a real working code with tests, docs & demos.
Not sure if source code should be hosted at zend server, could be just
collection of metadata.
To be included/listed in community repo component should meet certain
requirements:
- ZF coding and naming standards
- inital tests
- docs
At the end of the day looks much like PEAR. Also it's a good place for
little helpers like filters, validators, form elements etc.

-- level 3: ZF applications/modules
Core & CR teams have no control over how modules are created &
distributed. So one installs module at his own risk.
Yet ZF could encourage module authors to meet certain criteria and
provide some basic foundation for modules: configuration, bootstrapping


Denis

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Weekly Status Update and IRC Meeting!

Gregory
In reply to this post by weierophinney
- Should a module contain a single namespace?

Yes. Some people would have kittens trying to explain to others
where/how to locate files?

- Should all classes in a module follow PSR-0 guidelines?

What is the naming convention of the Controller class going to be?

- Modules: Should we allow autodiscovery at runtime?

My preference is no. Otherwise how can we prevent certain modules from
not being accessible within particular circumstances/domains?

A clearer understanding of the routing mechanism in ZF2 might help
answer some of the module related questions?

- Distribution: Seems like there are two objectives, discrete
components, and overall application framework? Without having studied
much of Symfony I can say hunting for classes seems like a pain. I'm
wondering if ZF should have a tiered namespace approach.

Zend - Discrete Components.

Zf - Application layer framework

The Zf namespace would then glue together the discrete Zend
components, i.e. this layer could provide a more tightly coupled API.

For example there could be a Zf\Application\Context which would extend
Zend\Di\DependencyInjection, this Zf class could then provide hard
coded convenience methods, such as getSessionManager (or just
getSession).

If I can deviate slightly, shouldn't there be the possibility to
Manually create explicit (convenience) methods used via the DI
Container, e.g getSession, rather than having reliance on
configuration or introspection?

Another Zf layer example, might be having a DB handler that implicitly
supports caching?

--
Greg

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Weekly Status Update and IRC Meeting!

Artur Bodera
Greg and Denis - please don't hijack.
We have 3 thread dedicated to modules. Please post there.

--
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]


On Wed, Aug 31, 2011 at 9:01 AM, Greg <[hidden email]> wrote:

> - Should a module contain a single namespace?
>
> Yes. Some people would have kittens trying to explain to others
> where/how to locate files?
>
> - Should all classes in a module follow PSR-0 guidelines?
>
> What is the naming convention of the Controller class going to be?
>
> - Modules: Should we allow autodiscovery at runtime?
>
> My preference is no. Otherwise how can we prevent certain modules from
> not being accessible within particular circumstances/domains?
>
> A clearer understanding of the routing mechanism in ZF2 might help
> answer some of the module related questions?
>
> - Distribution: Seems like there are two objectives, discrete
> components, and overall application framework? Without having studied
> much of Symfony I can say hunting for classes seems like a pain. I'm
> wondering if ZF should have a tiered namespace approach.
>
> Zend - Discrete Components.
>
> Zf - Application layer framework
>
> The Zf namespace would then glue together the discrete Zend
> components, i.e. this layer could provide a more tightly coupled API.
>
> For example there could be a Zf\Application\Context which would extend
> Zend\Di\DependencyInjection, this Zf class could then provide hard
> coded convenience methods, such as getSessionManager (or just
> getSession).
>
> If I can deviate slightly, shouldn't there be the possibility to
> Manually create explicit (convenience) methods used via the DI
> Container, e.g getSession, rather than having reliance on
> configuration or introspection?
>
> Another Zf layer example, might be having a DB handler that implicitly
> supports caching?
>
> --
> Greg
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Weekly Status Update and IRC Meeting!

weierophinney
Administrator
In reply to this post by DeNix
-- Denis Portnov <[hidden email]> wrote
(on Wednesday, 31 August 2011, 07:27 AM +0400):

> In my opinion both questions: modules and zf2 distribution lead to
> one question worth discussing at IRC meeting:
>
> What ZF2 ecosystem will look like?
>
> based on discussions @ ML I have this picture in mind:
>
> -- level 1: ZF
> MVC/component framework distributed and maintained by Zend team
> standard distro: Core + MVC
> extended distro: Core + MVC + Extras
>
> -- level 2: Community repo
> Resembles ZF structure but each component(or extension to the
> standard ZF class) is maintained by its author.
> No CLA requirements. Possibly some CR team involvment.


One note: if a component aims to someday be part of the main ZF repo,
all authors would need to sign the CLA. *sigh*


> All vendor's classes are under vendor specfic namespace.
> One scenario for community repo is classes that extend ZF functionality,
> so I one will be able to create something like MyLib/Http/Client
> (extends Zend\Http\Client) with extra features
> Another scenario is an early adoption/preview of proposals. So one
> could show his proposal as a real working code with tests, docs &
> demos.
> Not sure if source code should be hosted at zend server, could be
> just collection of metadata.
> To be included/listed in community repo component should meet
> certain requirements:
> - ZF coding and naming standards
> - inital tests
> - docs
> At the end of the day looks much like PEAR. Also it's a good place
> for little helpers like filters, validators, form elements etc.
>
> -- level 3: ZF applications/modules
> Core & CR teams have no control over how modules are created &
> distributed. So one installs module at his own risk.
> Yet ZF could encourage module authors to meet certain criteria and
> provide some basic foundation for modules: configuration,
> bootstrapping

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Weekly Status Update and IRC Meeting!

weierophinney
Administrator
In reply to this post by Gregory
-- Greg <[hidden email]> wrote
(on Wednesday, 31 August 2011, 02:01 AM -0500):
> - Should a module contain a single namespace?
>
> Yes. Some people would have kittens trying to explain to others
> where/how to locate files?
>
> - Should all classes in a module follow PSR-0 guidelines?
>
> What is the naming convention of the Controller class going to be?

In the prototypes I've been doing so far, there are explicit mappings
between a controller name as discovered by the router, and the
controller class; this is part of configuration. We will likely
introduce a conventions-based discovery ala ZF1, but the above is more
flexible and makes it easier to re-purpose code as controllers later.

All controllers in the zf-quickstart prototype are in a "Controller"
subnamespace: QuickStart\Controller\GuestbookController.

> - Modules: Should we allow autodiscovery at runtime?
>
> My preference is no. Otherwise how can we prevent certain modules from
> not being accessible within particular circumstances/domains?
>
> A clearer understanding of the routing mechanism in ZF2 might help
> answer some of the module related questions?

I'll leave DASPRiD to answer this... if he's lurking on the ML...

> - Distribution: Seems like there are two objectives, discrete
> components, and overall application framework? Without having studied
> much of Symfony I can say hunting for classes seems like a pain. I'm
> wondering if ZF should have a tiered namespace approach.
>
> Zend - Discrete Components.
>
> Zf - Application layer framework
>
> The Zf namespace would then glue together the discrete Zend
> components, i.e. this layer could provide a more tightly coupled API.
>
> For example there could be a Zf\Application\Context which would extend
> Zend\Di\DependencyInjection, this Zf class could then provide hard
> coded convenience methods, such as getSessionManager (or just
> getSession).

Interesting. Can you elaborate on this in a new thread, please?

> If I can deviate slightly, shouldn't there be the possibility to
> Manually create explicit (convenience) methods used via the DI
> Container, e.g getSession, rather than having reliance on
> configuration or introspection?

I've actually created functionality already that compiles a service
locator class from a configured DI instance. That class has specific
getters for each class exposed by the DI container. While the interface
simply defines get(), there's nothing stopping you from using those
other methods.

> Another Zf layer example, might be having a DB handler that implicitly
> supports caching?

That will actually be possible through an event HandlerAggregate
dedicated to DB caching -- you'd simply register it with the DB
adapter's EventManager instance.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Weekly Status Update and IRC Meeting!

DeNix
In reply to this post by Artur Bodera
My post had no intention to hijack modules thread.
I was talking about ecosystem, separation of responsibility.

Regarding community repo and CLA,
yes, if component aims to be part of ZF distribution authors should sign
CLA, no question about it
But for community repo I don't see such requirement nessesary, not sure
even 50% of components will end up as part of ZF distribution

Denis

On 31.08.2011 11:41, Artur Bodera wrote:
> Greg and Denis - please don't hijack.
> We have 3 thread dedicated to modules. Please post there.
>
> --
>       __
>      /.)\   +48 695 600 936
>      \(./ [hidden email] <mailto:[hidden email]>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Weekly Status Update and IRC Meeting!

Kevin McArthur-2
In reply to this post by weierophinney
I've added discussion of the modular items I see as outstanding to the wiki.

Let me know if between Rob and I we have em all covered please.

--

Kevin

On 11-08-30 02:39 PM, Matthew Weier O'Phinney wrote:

> I've just posted a weekly status update:
>
>   * http://framework.zend.com/zf2/blog/entry/2011-08-30-Dev-status-update
>
> Also, a reminder: the IRC meeting is TOMORROW!!!!!
>
> Current agenda is here (I seeded it because nobody else had):
>
>   * http://framework.zend.com/wiki/display/ZFDEV2/2011-08-31+Meeting+Agenda
>
> Please read, update, vote, etc.
>
> Talk to you all tomorrow!
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Weekly Status Update and IRC Meeting!

padraicb
In reply to this post by weierophinney
Reminds me - we could use an EventManager blog post to get something relevant on a Google Search ;). I'll write something, but I won't get to it for a few weeks at least. Any chance you could throw up an EventManager intro sometime, Matthew? If you work on increasing your caffeine intake, I'm sure you can squeeze it into your schedule with a very minor risk of being driven insane.

 
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team



----- Original Message -----
> From: Matthew Weier O'Phinney <[hidden email]>
> To: [hidden email]
> Cc:
> Sent: Wednesday, August 31, 2011 2:31 PM
> Subject: Re: [zf-contributors] Weekly Status Update and IRC Meeting!
>

>
>>  Another Zf layer example, might be having a DB handler that implicitly
>>  supports caching?
>
> That will actually be possible through an event HandlerAggregate
> dedicated to DB caching -- you'd simply register it with the DB
> adapter's EventManager instance.
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [hidden email]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Weekly Status Update and IRC Meeting!

weierophinney
Administrator
-- Pádraic Brady <[hidden email]> wrote
(on Wednesday, 31 August 2011, 12:11 PM -0700):
> Reminds me - we could use an EventManager blog post to get something
> relevant on a Google Search ;). I'll write something, but I won't get
> to it for a few weeks at least. Any chance you could throw up an
> EventManager intro sometime, Matthew? If you work on increasing your
> caffeine intake, I'm sure you can squeeze it into your schedule with a
> very minor risk of being driven insane.

Actually, I wrote some manual pages a few weeks ago that should give a
good overview. :)

    https://github.com/zendframework/zf2/blob/master/documentation/manual/en/module_specs/Zend_EventManager-EventManager.xml

However, I could likely create a blog post as well. /me queues one up


> ----- Original Message -----
> > From: Matthew Weier O'Phinney <[hidden email]>
> > To: [hidden email]
> > Cc:
> > Sent: Wednesday, August 31, 2011 2:31 PM
> > Subject: Re: [zf-contributors] Weekly Status Update and IRC Meeting!
> >
> > >  Another Zf layer example, might be having a DB handler that
> > >  implicitly supports caching?
> >
> > That will actually be possible through an event HandlerAggregate
> > dedicated to DB caching -- you'd simply register it with the DB
> > adapter's EventManager instance.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]