Development

IRCLogs20110203 (diff)

You must first sign up to be able to contribute.

Changes between Version 3 and Version 4 of IRCLogs20110203

Show
Ignore:
Author:
lsmith (IP: 217.162.131.234)
Timestamp:
02/14/11 22:34:48 (7 years ago)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • IRCLogs20110203

    v3 v4  
    22                          
    33http://doodle.com/f6m34z9vumff8av7 
    4  
    5 == RFC and update on Extension refactoring Options == 
    64 
    75== skip bootstrap.php in app_dev.php == 
    119= IRC logs = 
    1210{{{ 
    13 Feb 03 11:01:18 <lsmith>        ok .. lets start the meeting 
    14 Feb 03 11:01:38 *       jonwage (~jwage@c-98-240-88-160.hsd1.tn.comcast.net) has joined #symfony-dev 
    15 Feb 03 11:01:39 <lsmith>        just a small note .. i have stopped writing a summary .. instead we will just have the log and the list of topics 
    16 Feb 03 11:01:54 <lsmith>        i think that is probably sufficient .. and safes me the work writing a summary 
    17 Feb 03 11:01:58 *       ajessu (~albert@25.Red-81-35-223.dynamicIP.rima-tde.net) has joined #symfony-dev 
    18 Feb 03 11:02:23 <lsmith>        first topic .. RFC and update on Extension refactoring Options: http://bit.ly/gjJnGf 
    19 Feb 03 11:02:26 *       becky (~becky@xd8ad02da.ip.e-nt.net) has joined #symfony-dev 
    20 Feb 03 11:02:30 <lsmith>        jmikola|w, weaverryan? 
    21 Feb 03 11:02:45 *       bobthecow (~bobthecow@unaffiliated/bobthecow) has left #symfony-dev 
    22 Feb 03 11:02:47 <jmikola|w>     sure 
    23 Feb 03 11:03:06 <weaverryan>    hit it - I'm here now too 
    24 Feb 03 11:03:19 <jmikola|w>     so, weaverryan and i were playing around with extension refactoring last week, and over the weekend johanness started writing a fluent interface to model a config's schema 
    25 Feb 03 11:03:26 *       bobthecow (~bobthecow@unaffiliated/bobthecow) has joined #symfony-dev 
    26 Feb 03 11:03:33 <lsmith>        bschussek: are you around? next topic would be your recent refactorings 
    27 Feb 03 11:03:34 <jmikola|w>     his mailing list post from last night revealed the implementation with respect to security extension 
    28 Feb 03 11:03:39 <bschussek>     sure 
    29 Feb 03 11:04:09 <lsmith>        https://github.com/schmittjoh/symfony/blob/config/src/Symfony/Bundle/SecurityBundle/DependencyInjection/Configuration.php 
    30 Feb 03 11:04:23 *       ndusan has quit (Quit: ndusan) 
    31 Feb 03 11:04:24 <jmikola|w>     so, we should probably take a moment over the coming day or two to look at that and port it over to other extensions 
    32 Feb 03 11:04:44 <lsmith>        jmikola|w: this change hasnt been pulled yet ... has it? 
    33 Feb 03 11:04:46 <jmikola|w>     weaverryan: correct me if i'm wrong, but i think that will only replace our merging... and most of the register() methods (as they exist in FrameworkExtension) would remain as-is 
    34 Feb 03 11:05:10 <jmikola|w>     lsmith: it actually may have, i don't see any open pulls from johanness  on symfony 
    35 Feb 03 11:05:23 <lsmith>        i never saw a pull for it .. 
    36 Feb 03 11:05:35 <jmikola|w>     oh, perhaps it's just in his personal fork then 
    37 Feb 03 11:05:35 <weaverryan>    I think the system itself has been merged in 
    38 Feb 03 11:05:44 <lsmith>        yup .. https://github.com/fabpot/symfony/blob/config/src/Symfony/Bundle/SecurityBundle/DependencyInjection/Configuration.php points nowhere 
    39 Feb 03 11:05:52 <jmikola|w>     johanness had a lot of "wip" commits to his fork yesterday for this :) 
    40 Feb 03 11:06:05 <lsmith>        so you 3 agree that this is easy to understand, maintainable and covers all the cases? 
    41 Feb 03 11:06:07 *       ornicar (~ornicar@66.87.8.32) has joined #symfony-dev 
    42 Feb 03 11:06:19 <weaverryan>    so yes, this would basically make the work of the extension class itself single-fold: to actually setup the DIC based on the options 
    43 Feb 03 11:06:27 <johanness>     i've been working on the process a lot, it's now basically done in three steps: 1. normalization, 2. merging, 3. finalization (adding defaults, validation) 
    44 Feb 03 11:06:29 <weaverryan>    the merging, validation, and normalization would take place elsewhere 
    45 Feb 03 11:06:32 <jmikola|w>     i'm slightly concerned it might be too much for other bundle developers to jump into, but it's do-able certainly for core extensions 
    46 Feb 03 11:06:40 <johanness>     the normalization has been merged 
    47 Feb 03 11:07:12 <jmikola|w>     by that i mean it's a learning curve; hopefully it only appears more daunting than it actually is :) 
    48 Feb 03 11:07:18 <weaverryan>    johanness: are the "default" values specified via this method or in a different way? 
    49 Feb 03 11:07:41 <johanness>     weaverryan, they are attached to the nodes for scalars, ->defValue($value) 
    50 Feb 03 11:07:51 <johanness>     arrays cannot have defaults 
    51 Feb 03 11:08:09 <jmikola|w>     johanness: by that you mean things like "options" arrays? 
    52 Feb 03 11:08:21 <weaverryan>    I would disagree with that - I'd rather have this only cover merging and normalization - I think default should be kept in a YAML file and be the first round of "configuration" sent through the system 
    53 Feb 03 11:08:42 <lsmith>        so this means that all the defaults for stuff are moved into the extension code and no longer live inside the DIC configs? 
    54 Feb 03 11:08:46 <johanness>     weaverryan, that's not possible since you can have a dynamic number of elements in an array 
    55 Feb 03 11:08:57 <johanness>     adding defaults must therefore be done at the end 
    56 Feb 03 11:09:04 <johanness>     when the entire structure of the config is known 
    57 Feb 03 11:09:11 <jmikola|w>     lsmith: these defaults are a bit different than the default params in DIC configs 
    58 Feb 03 11:09:23 <jmikola|w>     these are more like defaults if you just load your extension with ~ in yaml 
    59 Feb 03 11:09:32 <johanness>     lsmith, i've started to move defaults into the configuration class yes 
    60 Feb 03 11:09:59 <lsmith>        what gets me with all of this is that its now very hard to to figure out defaults 
    61 Feb 03 11:10:06 <jmikola|w>     johanness how does your schema for for weaverryan's mongo connection's array?  weaverryan if you want to explain that 
    62 Feb 03 11:10:07 <weaverryan>    johanness: I don't quite understand - with the implementation that jmikola|w and I have, the defaults are specified in the beginning and then everything is merged on top of them 
    63 Feb 03 11:10:14 <jmikola|w>     i know that was a concern of yours from saturday 
    64 Feb 03 11:10:19 <lsmith>        i guess it would then require us to ensure that there is documentation for the defaults 
    65 Feb 03 11:10:22 <lsmith>        independent of the code 
    66 Feb 03 11:10:38 <lsmith>        previously in theory the DIC config's served as documentation on the defaults 
    67 Feb 03 11:10:56 <johanness>     weaverryan, for example if i have defaults for a firewall, then i don't know what firewall names the user has configured, and how many firewalls he has configured, so i cannot lay out a default config before actually parsing his configs 
    68 Feb 03 11:11:47 <jmikola|w>     johanness: given that firewalls have different keys to identify them, you can still define structure and default values in your schema? 
    69 Feb 03 11:12:02 <weaverryan>    hmm 
    70 Feb 03 11:12:02 <jmikola|w>     weaverryan: i suppose that's one reason such defaults couldn't readily be defined in a static yaml file 
    71 Feb 03 11:12:13 <johanness>     in my schema yes, that's basically what the prototype() is used for 
    72 Feb 03 11:12:23 <jmikola|w>     although simple options (not under dynamic keys) are arguably more clear in static yaml :) 
    73 Feb 03 11:12:33 <weaverryan>    I'm not convinced yet - but I need to look into it more 
    74 Feb 03 11:12:54 <weaverryan>    if you have default options for *all* firewalls, i don't see why that array couldn't be specified in YAML and merged in first 
    75 Feb 03 11:12:56 *       tecbot (~tecbot@p54B338E5.dip.t-dialin.net) has joined #symfony-dev 
    76 Feb 03 11:13:12 <weaverryan>    assuming that you apply these default values onto the configured firewalls at the very end of the process (probably manually) 
    77 Feb 03 11:13:12 <jmikola|w>     weaverryan: what would the array be indexed by though?  
    78 Feb 03 11:13:15 <lsmith>        weaverryan: yeah .. exactly 
    79 Feb 03 11:13:30 <jmikola|w>     it'd have to be some reserved key for such purposes, like _prototype:  
    80 Feb 03 11:13:39 <weaverryan>    well, I basically don't know anything about firewalls - so i'm out of my element on specific to that part :) 
    81 Feb 03 11:13:41 <jmikola|w>     thinking  both about security firewalls and your doctrine connections 
    82 Feb 03 11:13:49 <jmikola|w>     i think they're quite similar in that respect 
    83 Feb 03 11:14:11 <weaverryan>    connections: [] 
    84 Feb 03 11:14:13 <jmikola|w>     firewalls is a collection of structured config sub-trees... just with dynamic keys 
    85 Feb 03 11:14:16 <weaverryan>    connection_default: [] 
    86 Feb 03 11:14:35 <weaverryan>    I'd break it up like that and then apply the connection_default values onto each connection at the end 
    87 Feb 03 11:14:39 <weaverryan>    *maybe* 
    88 Feb 03 11:14:45 <lsmith>        anyway .. we are approaching the end of the timebox 
    89 Feb 03 11:14:48 <weaverryan>    I just really think we should work toward getting defaults into YAML 
    90 Feb 03 11:14:51 <johanness>     you could ofc load your defaults from a config file before passing them to ->defValue() 
    91 Feb 03 11:14:58 <weaverryan>    that's ok - I need to do more research anyways 
    92 Feb 03 11:15:04 <lsmith>        i guess the news is that things are progressing .. but are not yet ready for people to start and migrate to 
    93 Feb 03 11:15:06 <jmikola|w>     ok, also i think we should loop in beberlei later on, as he was working on non-ODM doctrine extensions 
    94 Feb 03 11:15:08 <avalanche123>  weaverryan +1 on defaults in YAML 
    95 Feb 03 11:15:17 <bschussek>     weaverryan +1 
    96 Feb 03 11:15:56 <jmikola|w>     lsmith: i guess we can move on 
    97 Feb 03 11:16:05 <lsmith>        +1 .. i also think its important to have all defaults for all possible cases as clearily available as possible 
    98 Feb 03 11:16:07 <lsmith>        Recent Form refactoring: http://bit.ly/e42W1m http://bit.ly/hLWcEd 
    99 Feb 03 11:16:09 <weaverryan>    ok, we'll figure it out then - maybe like johanness said, we can load them from YAML and have them applied to the correct ->defValue() 
    100 Feb 03 11:16:10 <lsmith>        bschussek ? 
    101 Feb 03 11:16:35 <bschussek>     I have simplified Form construction to reduce a number of bugs 
    102 Feb 03 11:16:54 <bschussek>     I won't go into much detail, but the documentation can be found here http://docs.symfony-reloaded.org/master/guides/forms/overview.html 
    103 Feb 03 11:17:06 <bschussek>     I have updated it and will update the rest in the following weeks 
    104 Feb 03 11:17:33 <bschussek>     the doc will encourage creating custom Form classes as best practice 
    105 Feb 03 11:17:40 <lsmith>        like we talked about .. imho there is still a need for a FormBuilder .. but i do not have time to write one atm 
    106 Feb 03 11:18:01 <bschussek>     lsmith: I agree, so if anyone has time and wants to improve Form integration in the DIC, tell me 
    107 Feb 03 11:18:15 <lsmith>        just to show an example: 
    108 Feb 03 11:18:16 <bschussek>     questions? 
    109 Feb 03 11:18:16 <lsmith>        https://github.com/FriendsOfSymfony/UserBundle/blob/master/Resources/config/form.xml#L23 
    110 Feb 03 11:18:38 <lsmith>        https://github.com/FriendsOfSymfony/UserBundle/blob/master/Controller/UserController.php#L104 
    111 Feb 03 11:18:46 <lsmith>        would be nice to be able to set the validation groups inside the controller 
    112 Feb 03 11:18:58 <lsmith>        so if anyone has time .. would be great :) 
    113 Feb 03 11:19:03 <bschussek>     I agree. I don't think we have much to discuss here though 
    114 Feb 03 11:19:22 <lsmith>        btw .. the UserBundle has been updated with the new approach 
    115 Feb 03 11:19:26 <jmikola|w>     kriswallsmith: did you talk to bschussek about wanting to bind non-POST stuff to a form? 
    116 Feb 03 11:19:31 <lsmith>        so this can be used to play around if needed 
    117 Feb 03 11:19:40 <bschussek>     jmikola|w: I'm aware of this problem 
    118 Feb 03 11:19:47 <jmikola|w>     avalanche123: and you had concerns about supporting methods other than POST for API/Rest concerns 
    119 Feb 03 11:19:50 <bschussek>     my approach to fix this is to add a "method" option to Form 
    120 Feb 03 11:19:57 <bschussek>     the questions are: 
    121 Feb 03 11:20:09 <bschussek>     1. where do we get data from for PUT requests? 
    122 Feb 03 11:20:11 <jmikola|w>     kriswallsmith's specific case was binding from session, so i'm not sure that'd match a method 
    123 Feb 03 11:20:21 <avalanche123>  indeed, I had concerns, and I don't think form should even care about the method 
    124 Feb 03 11:20:24 <jmikola|w>     as he was implementing something like sf1 admin generator filters, which store their state in session 
    125 Feb 03 11:20:25 <bschussek>     2. when can we consider a GET request submitted? When the variable with the form's name is available? 
    126 Feb 03 11:20:37 <avalanche123>  bschussek, let them populate Request::$request and form use that to perform binding 
    127 Feb 03 11:20:59 <bschussek>     avalanche123: ok, you would have to talk to Fabien about that 
    128 Feb 03 11:21:03 <bschussek>     question 2 remains 
    129 Feb 03 11:21:09 <jmikola|w>     bschussek: is binding from a generic array out of the question?  my other use case was having an action that is only forwarded to as a sub-request... so it didn't have query/post data available per-se 
    130 Feb 03 11:21:28 <bschussek>     jmikola|w: no it isn't. bind() in reality is just a shortcut method 
    131 Feb 03 11:21:37 <bschussek>     you can copy the code into your application and customize it 
    132 Feb 03 11:21:51 <bschussek>     setData(), submit() and validate() are all public 
    133 Feb 03 11:22:39 <bschussek>     any solution to question 2? 
    134 Feb 03 11:22:59 <jmikola|w>     re: #2, is that for auto-binding? 
    135 Feb 03 11:23:03 <bschussek>     yes 
    136 Feb 03 11:23:12 <mvrhov>        we don't autobind in that case? 
    137 Feb 03 11:23:20 <kriswallsmith> auto-binding? 
    138 Feb 03 11:23:32 <jmikola|w>     what is the use case for such a thing? 
    139 Feb 03 11:23:36 <bschussek>     kriswallsmith: bind() reads the request method and decides whether a form was submitted or not 
    140 Feb 03 11:23:39 *       webPragmatist (~webby@cpe-76-183-154-75.tx.res.rr.com) has joined #symfony-dev 
    141 Feb 03 11:23:42 <jmikola|w>     i wasn't aware posts are auto-bound 
    142 Feb 03 11:23:43 *       webPragmatist has quit (Changing host) 
    143 Feb 03 11:23:43 *       webPragmatist (~webby@unaffiliated/webpragmatist) has joined #symfony-dev 
    144 Feb 03 11:23:44 <bschussek>     for a GET request, this decision is not able 
    145 Feb 03 11:23:53 <bschussek>     -able -easy 
    146 Feb 03 11:23:56 <kriswallsmith> what is the benefit of this? 
    147 Feb 03 11:23:57 <bschussek>     +easy 
    148 Feb 03 11:23:59 <bschussek>     sorry 
    149 Feb 03 11:24:03 <bschussek>     kriswallsmith: less code to write 
    150 Feb 03 11:24:23 <kriswallsmith> um, i read that as "magic" ;) 
    151 Feb 03 11:24:31 <avalanche123>  +1 on magic 
    152 Feb 03 11:24:43 <bschussek>     kriswallsmith: if you want, yes. In sf1 we had to repeat the same pattern everytime when we built a form 
    153 Feb 03 11:24:45 <jmikola|w>     bschussek: the user still has to call bind() themselves, even for GET, right? 
    154 Feb 03 11:24:45 <kriswallsmith> less magic, more explicit 
    155 Feb 03 11:24:49 <bschussek>     and 90% where default cases 
    156 Feb 03 11:25:13 <kriswallsmith> how do you disable auto-binding? 
    157 Feb 03 11:25:21 <bschussek>     kriswallsmith: by doing everything manually 
    158 Feb 03 11:25:26 <jmikola|w>     could there be an extra parameter that choses the Request property to bind from, defaulting to "request" ? 
    159 Feb 03 11:25:29 <bschussek>     i.e., calling submit() 
    160 Feb 03 11:25:32 <bschussek>     and passing the parameters 
    161 Feb 03 11:25:45 <bschussek>     jmikola|w: this extra parameter equals the form name 
    162 Feb 03 11:25:48 <kriswallsmith> how does that disable auto-binding? 
    163 Feb 03 11:25:48 <lsmith>        5 more minutes in this timebox 
    164 Feb 03 11:25:56 <kriswallsmith> i'll take a look at the code 
    165 Feb 03 11:26:01 <bschussek>     kriswallsmith: do that 
    166 Feb 03 11:26:01 <kriswallsmith> but auto-binding sounds too magic to me 
    167 Feb 03 11:26:04 <bschussek>     there is nothing automatic 
    168 Feb 03 11:26:08 <bschussek>     just one shortcut method 
    169 Feb 03 11:26:16 <kriswallsmith> ok 
    170 Feb 03 11:26:22 <jmikola|w>     bschussek: GET submissions can still be indexed under the form name; but if you're binding from GET you probably don't want to array merge request/files together 
    171 Feb 03 11:26:28 <jmikola|w>     you'd just want to use query instead 
    172 Feb 03 11:26:31 *       nielsie has quit (Ping timeout: 250 seconds) 
    173 Feb 03 11:26:39 <bschussek>     jmikola|w: yes, we can do that in bind() 
    174 Feb 03 11:26:44 <lsmith>        bschussek: "auto binding" is calling bind() and not auto binding is calling 3 methods 
    175 Feb 03 11:26:51 <bschussek>     lsmith: exactloy 
    176 Feb 03 11:26:52 <jmikola|w>     kriswallsmith: i probably mispoke when i said "auto-binding"... it's just the bind() method the user must call 
    177 Feb 03 11:27:07 <kriswallsmith> i see, i thought bind was "calling itself" 
    178 Feb 03 11:27:17 <jmikola|w>     bschussek: perhaps there can be a "strategy" option of sorts 
    179 Feb 03 11:27:19 <bschussek>     maybe an important informatoin: 
    180 Feb 03 11:27:20 <lsmith>        so its manual .. just bind() is a helper that handles most of the cases 
    181 Feb 03 11:27:21 <jmikola|w>     by default, it's request+files 
    182 Feb 03 11:27:34 <bschussek>     the old bind() (i.e. pulling the request parameters into the form) is now called submit() 
    183 Feb 03 11:27:59 <bschussek>     the new bind() is a shortcut method for setData(), submit() and validate(), which internally has the detection whether a request was submitted or not 
    184 Feb 03 11:28:12 <jmikola|w>     and it also generates the array to pass to submit() 
    185 Feb 03 11:28:17 <bschussek>     exactly 
    186 Feb 03 11:28:54 *       dbenjamin has quit (*.net *.split) 
    187 Feb 03 11:28:57 <jmikola|w>     is there a problem with a third bind() parameter to enforce strategy? i realize you might not want to create more methods like bindQuery willy-nilly 
    188 Feb 03 11:29:12 <bschussek>     strategy? 
    189 Feb 03 11:29:15 <lsmith>        ok .. so the open question is how to detect inside bind() if it should call submit() for GET requests 
    190 Feb 03 11:29:23 <bschussek>     lsmith: exactly 
    191 Feb 03 11:29:47 <bschussek>     is it enough to check whether a query parameter with the form's name is available? 
    192 Feb 03 11:29:47 <jmikola|w>     bschussek: current behavior as i see it is:  array('request', 'files') 
    193 Feb 03 11:30:01 <bschussek>     jmikola|w: sure, but GET is not implemented if you look 
    194 Feb 03 11:30:03 <lsmith>        i guess a parameter with the name of the GET parameter that has to be set to something that evaluates to trye 
    195 Feb 03 11:30:04 <lsmith>        true 
    196 Feb 03 11:30:16 <jmikola|w>     ah, because you just check the method, you don't check if post vars have form name index set 
    197 Feb 03 11:30:22 <bschussek>     yes 
    198 Feb 03 11:30:29 <jmikola|w>     so GET should certainly do that... but also ensure it's a GET method, no? 
    199 Feb 03 11:30:31 <lsmith>        ok .. we have reached the end of the timebox 
    200 Feb 03 11:30:35 <bschussek>     yes 
    201 Feb 03 11:30:39 <bschussek>     let's go with this solution 
    202 Feb 03 11:30:44 <bschussek>     if there are drawbacks, we'll discover 
    203 Feb 03 11:30:46 <lsmith>        Coordinating SFLive Hackday: http://bit.ly/fSlbh5 
    204 Feb 03 11:31:10 <lsmith>        so i put this one on the agenda because i want to make sure that especially people who are not in SF can ensure they do useful work 
    205 Feb 03 11:31:29 <lsmith>        now i am not sure if there is anyone who is attending SF around tonight? 
    206 Feb 03 11:31:31 <lsmith>        i guess kriswallsmith 
    207 Feb 03 11:31:36 <naderman>      I'm here too 
    208 Feb 03 11:31:39 <pgodel_work>   I walso wanted to know what was the plan in SF, but fabpot is not here 
    209 Feb 03 11:31:52 <lsmith>        what i was wondering about is we have johanness and bschussek who are responsible for some parts 
    210 Feb 03 11:31:55 <lsmith>        but what about others? 
    211 Feb 03 11:32:11 <kriswallsmith> i arrive wednesday afternoon 
    212 Feb 03 11:32:11 <lsmith>        also i think one group of people needs to run static code analyizers over the code 
    213 Feb 03 11:32:19 <bschussek>     lsmith: +1 
    214 Feb 03 11:32:24 <lsmith>        i did this a bit .. and found a ton of screwed up use statements and missing variables 
    215 Feb 03 11:32:39 <pgodel_work>   lsmith: ok 
    216 Feb 03 11:32:40 <lsmith>        though its a bit tedious work .. since the analyzers i tried all gave about 70% false positives 
    217 Feb 03 11:32:53 <pgodel_work>   ouch 
    218 Feb 03 11:32:56 <jmikola|w>     lsmith: perhaps you can just publish the report on the mailing list?  but it would be good to coordinate one team of folks to actually fix all the changes to prevent a merge nightmare 
    219 Feb 03 11:33:19 <lsmith>        jmikola|w: the rest is inside my phpStorm IDE .. and it also is a lot of work 
    220 Feb 03 11:33:29 <lsmith>        because there are just too many files to just scan all of Symfony 
    221 Feb 03 11:33:31 <naderman>      I assume we'll be on IRC during the hackdays so can also coordinate stuff in here 
    222 Feb 03 11:33:31 <jmikola|w>     even if it's a list of things for folks to analyze and discover things are just false positives, it would be a good diving board into scouring the code 
    223 Feb 03 11:33:37 <lsmith>        so it would need to be done by separate teams of people 
    224 Feb 03 11:33:51 <lsmith>        it just sucks if we waste half of the saturday trying to get organized 
    225 Feb 03 11:34:18 <naderman>      lsmith: well is there someone who wants to help but doesn't know what to do? 
    226 Feb 03 11:34:30 <lsmith>        naderman: i am sure there will be quite a few 
    227 Feb 03 11:34:41 <bschussek>     lsmith: what about collecting open tasks? 
    228 Feb 03 11:34:46 <pgodel_work>   who is going to be there on sat and sun ? 
    229 Feb 03 11:34:55 <lsmith>        we have a few people coming to Zurich 
    230 Feb 03 11:35:01 <bschussek>     I am in Z├╝rich 
    231 Feb 03 11:35:02 <naderman>      so indeed I think we should just collect tasks for those on the mailinglist 
    232 Feb 03 11:35:05 <jmikola|w>     bschussek: lsmith did do a good job at rounding through old ML posts this week :) 
    233 Feb 03 11:35:13 <naderman>      if anyone can think of anything that could be done during hackdays post it? 
    234 Feb 03 11:35:14 <lsmith>        i think static code analysis, going through open tickets are two areas 
    235 Feb 03 11:35:33 <jmikola|w>     if johanness' config normalizer is good to go, that would be a great task as well 
    236 Feb 03 11:35:37 <lsmith>        ok .. so please everyone post topics 
    237 Feb 03 11:35:42 <jmikola|w>     to knock out some extensions over the weekend 
    238 Feb 03 11:35:43 <lsmith>        or better yet .. i will create a wiki page 
    239 Feb 03 11:35:44 <pgodel_work>   naderman: I was expecting fabien to do that 
    240 Feb 03 11:35:49 <lsmith>        after the meeting 
    241 Feb 03 11:35:51 <naderman>      pgodel_work: me too, kind of 
    242 Feb 03 11:35:53 <lsmith>        and people add stuf there 
    243 Feb 03 11:36:00 <pgodel_work>   but yes, we should know ahead of time to not waste time 
    244 Feb 03 11:36:05 <bschussek>     I have a couple of open Form/Validator tickets on https://www.pivotaltracker.com/projects/130524 
    245 Feb 03 11:36:12 <lsmith>        i will try to coordinate stuff then 
    246 Feb 03 11:36:13 <bschussek>     so if there are too many bored people, they can help me :) 
    247 Feb 03 11:36:15 <lsmith>        as good as i can 
    248 Feb 03 11:36:22 <lsmith>        maybe i can get a hold of fabien tomorrow to discuss stuff 
    249 Feb 03 11:36:45 <lsmith>        ok? 
    250 Feb 03 11:36:48 <pgodel_work>   a wiki or a google doc for online collaboration would be very useful 
    251 Feb 03 11:36:48 <bschussek>     +1 
    252 Feb 03 11:36:48 <jmikola|w>     bschussek: is that replacing trac? 
    253 Feb 03 11:36:52 <jmikola|w>     or is it your personal tool 
    254 Feb 03 11:36:59 <lsmith>        pgodel_work: yeah i will put it on trac 
    255 Feb 03 11:37:01 <bschussek>     jmikola|w: my personal one, because trac sucks 
    256 Feb 03 11:37:31 <lsmith>        ok .. next topic then 
    257 Feb 03 11:37:33 <pgodel_work>   we also need to know what times 
    258 Feb 03 11:37:44 <pgodel_work>   this is going to be to coordinate local and remote people 
    259 Feb 03 11:37:46 <lsmith>        well zurich will be ahead of SF by quite a bit :) 
    260 Feb 03 11:37:54 <pgodel_work>   yup 
    261 Feb 03 11:38:22 <lsmith>        we have a lot of maybe's for Zurich .. 
    262 Feb 03 11:38:27 <lsmith>        will see who shows up 
    263 Feb 03 11:38:38 <lsmith>        anyway .. like i said .. i will create a wiki page 
    264 Feb 03 11:38:46 <pgodel_work>   good 
    265 Feb 03 11:38:48 <lsmith>        please add topics there, or send them to the mailinglist 
    266 Feb 03 11:38:50 <lsmith>        or ping me 
    267 Feb 03 11:38:55 <lsmith>        i will try to keep the wiki page organized 
    268 Feb 03 11:39:02 <lsmith>        moving on then .. 
    269 Feb 03 11:39:19 <lsmith>        uhm .. so next topic is Adding the view layer: http://bit.ly/eb8XAR http://bit.ly/hHjt6x 
    270 Feb 03 11:39:43 <lsmith>        i just carried that topic over since i always carry over topics that get a fair bit of votes the previous week that didnt get discussed 
    271 Feb 03 11:40:04 <lsmith>        at the same time since i originally proposed to reopen the topic .. i sort of got tired argueing over this 
    272 Feb 03 11:40:05 <naderman>      I'm not sure what Fabien's problem with an html encoder was 
    273 Feb 03 11:40:07 <mvrhov>        1st one is 404 
    274 Feb 03 11:40:12 *       ornicar has quit (Quit: WeeChat 0.3.4) 
    275 Feb 03 11:40:19 <naderman>      semantically that is exactly correct 
    276 Feb 03 11:40:21 <mvrhov>        1st link 
    277 Feb 03 11:40:23 <lsmith>        mvrhov: ah sorry .. 
    278 Feb 03 11:40:27 <lsmith>        its now all merged to master 
    279 Feb 03 11:40:32 <lsmith>        https://github.com/liip/ViewBundle/ 
    280 Feb 03 11:40:38 *       rooster has quit (Remote host closed the connection) 
    281 Feb 03 11:41:04 <lsmith>        naderman: yeah .. that was for me sort of the final nail in the coffin .. since first we were asked to create a serializer 
    282 Feb 03 11:41:07 <naderman>      the idea of the serializer is to serialize things, either into generic formats like JSON/XML or more specific ones like Atom or RSS 
    283 Feb 03 11:41:07 <lsmith>        and then we deliver that 
    284 Feb 03 11:41:17 <lsmith>        and implement the view .. and then we are told that we shouldnt use it for html 
    285 Feb 03 11:41:20 <naderman>      and HTML is just one of those more specific ones 
    286 Feb 03 11:41:24 <lsmith>        which sort of made the entire thing pointless 
    287 Feb 03 11:42:15 <lsmith>        so anyway .. if there are questions .. i can answer them .. if someone is willing to discuss this some more with fabien .. feel free 
    288 Feb 03 11:42:27 <naderman>      will do in SF 
    289 Feb 03 11:42:34 <lsmith>        ok next topic then .. 
    290 Feb 03 11:42:47 <lsmith>        [RFC] Config validation compiler pass: http://bit.ly/eCxUm1 
    291 Feb 03 11:42:57 <lsmith>        if i read this properly .. johanness said its already solved? 
    292 Feb 03 11:43:05 <lsmith>        by the synthetic attribute? 
    293 Feb 03 11:43:35 <jmikola|w>     i believe that was it from the ML post 
    294 Feb 03 11:44:35 <lsmith>        ok .. anyone have questions on this? 
    295 Feb 03 11:44:37 <lsmith>        otherwise moving on 
    296 Feb 03 11:44:41 <jmikola|w>     he said synthetic makes it possible, but it needs an addition to ResolveInvalidReferencesPass 
    297 Feb 03 11:45:16 <lsmith>        Third-party dependencies in Components Options: http://bit.ly/hcXLkb 
    298 Feb 03 11:45:37 <lsmith>        i guess this topic wasnt quote over for some 
    299 Feb 03 11:45:51 <lsmith>        then again none of the people unhappy seem to be around today 
    300 Feb 03 11:46:14 <lsmith>        so .. 
    301 Feb 03 11:46:25 <lsmith>        i guess there is nothing to discuss further .. 
    302 Feb 03 11:46:32 <lsmith>        ah no 
    303 Feb 03 11:46:39 <lsmith>        The directory structure does not work for model Options: http://bit.ly/eQcgcF 
    304 Feb 03 11:46:46 <lsmith>        i didnt have time to read up this thread myself yet 
    305 Feb 03 11:46:57 <lsmith>        not sure if there is anything left open 
    306 Feb 03 11:47:14 <rande> well ... 
    307 Feb 03 11:47:23 <jmikola|w>     lsmith: i have one more topic if you want to throw it out there 
    308 Feb 03 11:47:31 <rande> it is more about how people want to use bundle 
    309 Feb 03 11:47:40 <jmikola|w>     but i think the dir structure was rande's topic :) 
    310 Feb 03 11:47:54 <rande> and how they can extend model from this bundle 
    311 Feb 03 11:47:59 <rande> jmikola: yep 
    312 Feb 03 11:48:04 <jmikola|w>     rande: iirc you wanted to replace the model used instead of extending a base model from a bundle 
    313 Feb 03 11:48:05 *       igorw (~igorw@phpbb/developer/evil3) has joined #symfony-dev 
    314 Feb 03 11:48:11 <rande> rande = th0masr = Thomas R. 
    315 Feb 03 11:48:15 <jmikola|w>     akin to how templates would be overridden? 
    316 Feb 03 11:48:45 <rande> all ressources can be overridden 
    317 Feb 03 11:48:57 <rande> controller, routing, templates 
    318 Feb 03 11:48:59 <Stof>  I think adding complexity for bundle devs to make it possible to override the model is not a good idea: if you override the model, you also have to override the business logic using it. And then you are just overriding the bundle. 
    319 Feb 03 11:49:00 <rande> but not Model 
    320 Feb 03 11:49:03 <jmikola|w>     since doctrine is entirely namespace-dependent (by the model's class name), wouldn't you have to redefine the class with the same namespace?  and likely have a special autoloader line for it - if it were to sit in your own directory 
    321 Feb 03 11:49:07 <rande> look weird to be 
    322 Feb 03 11:49:18 <rande> to me 
    323 Feb 03 11:50:16 <Stof>  overriding the controller can be done only if you override the routing too (unless they are defined as services by the bundle dev) 
    324 Feb 03 11:50:30 <rande> Stof: I can apply your remark to bundle 
    325 Feb 03 11:50:50 <rande> why a bundle should be extendable ? 
    326 Feb 03 11:51:15 <jmikola|w>     Stof: i think there's good reason that controllers for extensible bundles should be services 
    327 Feb 03 11:51:16 <rande> the current implementation allows devs to reimplement/extends some parts 
    328 Feb 03 11:51:29 <jmikola|w>     but i'd argue controllers themselves aren't very extensible to begin with :) 
    329 Feb 03 11:51:33 <rande> option 1 : remove this option 
    330 Feb 03 11:51:45 <rande> option 2: make all elements extendable 
    331 Feb 03 11:52:06 <naderman>      option 3: make/keep the ones extensible for which it works well 
    332 Feb 03 11:52:13 <Stof>  jmikola|w: my point is saying that overriding controllers is possible *only* if the bundle dev designs his bundle this way. this is not always the case 
    333 Feb 03 11:52:18 <naderman>      I'm really not sure what exactly you are looking for 
    334 Feb 03 11:52:22 <kriswallsmith> you may be able to use the doctrine namespace alias mechanism 
    335 Feb 03 11:52:24 <jmikola|w>     rande: to the point of option 2, is this accomplished by FOS/UserBundle making the model class configurable? 
    336 Feb 03 11:52:34 <kriswallsmith> but that would require copying all model classes 
    337 Feb 03 11:52:35 <jmikola|w>     you're under no obligation to extend the base class, just implement the interface really 
    338 Feb 03 11:52:54 <kriswallsmith> rande: composition is probably the way to go 
    339 Feb 03 11:52:56 <rande> the issue about that is how do you use model constant ? 
    340 Feb 03 11:53:13 <jmikola|w>     what's "model constant"? 
    341 Feb 03 11:53:26 <rande> const STATUS_OK = 1 
    342 Feb 03 11:53:39 <naderman>      what is the issue 
    343 Feb 03 11:53:51 <jmikola|w>     for that, you could easily refer to the bundle's model class, no? 
    344 Feb 03 11:53:51 <Stof>  jmikola|w: this is true for the User class but you cannot make a class extensible when it is the target of a relation (this is why the Group entity is not extensible in FOSUB) 
    345 Feb 03 11:54:23 <naderman>      Stof: hmm that is indeed something that would be nice to change 
    346 Feb 03 11:54:24 <jmikola|w>     Stof: noted... in that case perhaps the bundle extension would have to be responsible for adjusting the class metadata in doctrine 
    347 Feb 03 11:54:29 <jmikola|w>     based on the configured classes  
    348 Feb 03 11:54:32 <rande> if you have a global namespace there is no problem 
    349 Feb 03 11:54:43 <jmikola|w>     that would move the relationship config out of mappings and into the extension's PHP 
    350 Feb 03 11:54:54 <rande> I don't want to declare all the class in the DIC configuration 
    351 Feb 03 11:55:03 <rande> image a project with 100 classes 
    352 Feb 03 11:55:04 <jmikola|w>     doesn't abide any existing convention, but i think it's certainly do-able to accomplish the goal 
    353 Feb 03 11:55:32 <Stof>  naderman: the issue is that the mapping needs to contain the FQCN of the target entity 
    354 Feb 03 11:55:40 <naderman>      yes I realise that 
    355 Feb 03 11:55:53 <jmikola|w>     kriswallsmith: does doctrine have namespace aliases for such a thing?   aliases used for mappings? 
    356 Feb 03 11:56:00 <rande> now the UserBundle:User does not works with association definition 
    357 Feb 03 11:56:18 <kriswallsmith> rande: ah, good point 
    358 Feb 03 11:56:21 <Stof>  rande: of course, the mapping is Doctrine stuff, not Symfony one 
    359 Feb 03 11:56:35 <rande> that why we need to use a global namesapce 
    360 Feb 03 11:56:57 <rande> is the only easy way to share and extends model 
    361 Feb 03 11:57:07 <naderman>      ok so the real issue here is that you cannot presently define a relationship in a mapping to a configurable class 
    362 Feb 03 11:57:28 <naderman>      so while you can make a model class configurable (as done for the user) you cannot do so when you need to define a relationship 
    363 Feb 03 11:57:40 <rande> naderman: is is possible to redifine the mapping at runtime 
    364 Feb 03 11:57:43 <Stof>  rande: extending the model is impossible with the way the mapping works 
    365 Feb 03 11:57:43 <jmikola|w>     naderman: if the mappings are static like annotations or xml... i maintain you could do it with PHP 
    366 Feb 03 11:58:09 <jmikola|w>     for something like FOS/UserBundle, there are only two classes so it wouldn't be too troublesome to do just that in the aim of extensibility  
    367 Feb 03 11:58:18 <jmikola|w>     obviously for 100 classes it'd be a nightmare :) 
    368 Feb 03 11:58:28 <rande> Stof : by extending I mean : define a mapped supper class in the Bundle and an Entity in the Application namespace 
    369 Feb 03 11:58:40 <naderman>      right, well I'd be interested in seeing that in the UserBundle 
    370 Feb 03 11:58:49 <Stof>  yeah, but where do you define the relations ? 
    371 Feb 03 11:59:06 <jmikola|w>     they'd have to be in the application version i'd think 
    372 Feb 03 11:59:26 <rande> https://github.com/sonata-project/NewsBundle/tree/master/Resources/config/doctrine/metadata/orm 
    373 Feb 03 11:59:30 <Stof>  thus, defining toMany relations in a mapped superclass breaks things if you have several entities extending it 
    374 Feb 03 11:59:32 <naderman>      is there some way to make the DoctrineBundle resolve references to entities? 
    375 Feb 03 12:00:02 <naderman>      so you could define them referencing an option instead of the actual FQCN 
    376 Feb 03 12:00:11 <rande> extending in not the correct term 
    377 Feb 03 12:00:21 <Stof>  rande: providing mapping for classes outside the bundle seems really weird 
    378 Feb 03 12:01:00 <Stof>  thus, this means that the bundle logic has to use the entity class which does not exist when downloading the bundle 
    379 Feb 03 12:01:08 <lsmith>        ok meeting time is officially over .. but feel free to continue :) 
    380 Feb 03 12:01:12 <rande> Stof : waht should be the good trade off ? 
    381 Feb 03 12:01:16 *       ornicar (~ornicar@66.87.6.165) has joined #symfony-dev 
    382 Feb 03 12:01:22 <Stof>  so this means distributing broken code 
    383 Feb 03 12:01:30 <lsmith>        jmikola|w: i guess the topic you had in mind should then best be moved to next week .. and you send a mail to the list? 
    384 Feb 03 12:01:45 <jmikola|w>     lsmith: i did shortly before our meeting 
    385 Feb 03 12:01:52 <jmikola|w>     hopefully i gets merged into fabpot/master before then though :) 
    386 Feb 03 12:01:55 <lsmith>        jmikola|w: ah ok 
    387 Feb 03 12:01:56 <rande> Stof : I use https://github.com/sonata-project/EasyExtendsBundle 
    388 Feb 03 12:02:11 <jmikola|w>     please comment on the ML if you have an opinion, though 
    389 Feb 03 12:02:24 <Stof>  yeah, but the project is in a broken state when you boot it to run the command 
    390 Feb 03 12:02:32 <rande> the bundle just create a full valid hierarchie in the Application namespace 
    391 Feb 03 12:02:45 <Stof>  so this means that all bundles needs to be able to boot in a broken state 
    392 Feb 03 12:02:54 <rande> yes 
    393 Feb 03 12:03:16 <rande> https://github.com/sonata-project/UserBundle/blob/master/FOSUserBundle.php 
    394 Feb 03 12:03:33 <rande> it is how I solve the issue in the UserBundle 
    395 Feb 03 12:03:42 <rande> class_exists! 
    396 Feb 03 12:03:56 <rande> I don't this solution is the best or ideal 
    397 Feb 03 12:04:01 <rande> it's just working 
    398 Feb 03 12:04:12 <Stof>  yeah, so then, you will have no exception if you don't create the class 
    399 Feb 03 12:04:15 <rande> I can extends model at the Application layer 
    400 Feb 03 12:04:33 <Stof>  and you will not know that your project is in a broken state 
    401 Feb 03 12:04:47 <rande> Stof : correct 
    402 Feb 03 12:05:02 <rande> but a project is always broken 
    403 Feb 03 12:05:09 <rande> you need to read the README file 
    404 Feb 03 12:05:17 <rande> to know how to install bundle ... 
    405 Feb 03 12:05:24 <rande> so it is a false problem 
    406 Feb 03 12:05:37 *       nic4m has quit (Read error: Operation timed out) 
    407 Feb 03 12:05:56 *       nic4m (~nic4m@77-56-168-111.dclient.hispeed.ch) has joined #symfony-dev 
    408 Feb 03 12:06:01 <Stof>  thus, you will have to do all the checks needed by the project at runtime as the bundle needs to be able to be broken at compile time 
    409 Feb 03 12:06:24 <Stof>  rande: the issue is that EasyExtendBundle require to *boot* the kernel in a broken state 
    410 Feb 03 12:06:36 *       bschussek (~bschussek@77-58-253-248.dclient.hispeed.ch) has left #symfony-dev 
    411 Feb 03 12:06:45 <rande> Stof : I get your point, I know ... 
    412 Feb 03 12:07:06 <lsmith>        i think its definately a major issue atm 
    413 Feb 03 12:07:16 <rande> but this can be achieve by creating a independant task 
    414 Feb 03 12:07:22 <lsmith>        didnt beberlei say that in 2.1 they attempt to solve the issue inside doctrine? 
    415 Feb 03 12:07:40 <Stof>  if this was decoupled from Symfony, it would be less an issue but then you will not be able to know what are the registered bundles 
    416 Feb 03 12:08:44 <Stof>  lsmith: it will solve the issue of overriding a mapping in a child class but this does not solve the issue of a bundle relying of the extending class in the controller and so on 
    417 Feb 03 12:08:56 <rande> well I can open the kernel and read those bundles or add an argument in the task to override one bundle only 
    418 Feb 03 12:09:11 <rande> these are issues but there are trivials 
    419 Feb 03 12:09:33 <rande> the main thing is : "we" need an agreement 
    420 Feb 03 12:09:50 <rande> is this solution should be a convention ? 
    421 Feb 03 12:09:57 <rande> yes or no 
    422 Feb 03 12:10:25 <jmikola|w>     rande: any consensus on this should likely be added to the best practices for bundles 
    423 Feb 03 12:10:31 <Stof>  the other issue is that it adds complexity for bundle devs as they have to build their code relying on entities extending their class instead of relying on classes they provide 
    424 Feb 03 12:10:55 <rande> jmikola|w: agreed 
    425 Feb 03 12:11:14 <rande> Stof : I don't see complexity 
    426 Feb 03 12:11:27 <rande> I use this solution with no pb 
    427 Feb 03 12:11:30 <jmikola|w>     i think that unless a bundle is so very specific that its classes need not be extended (something single-purpose like avalanche123's sitemap generator), the bundle dev should probably anticipate that his classes will need to be extended 
    428 Feb 03 12:12:13 <jmikola|w>     taking FOS/UserBundle as an example, the current classes are a mish-mash of various projects' business requirements, and i doubt most of us can use it without customization in various places 
    429 Feb 03 12:12:31 <Stof>  jmikola|w: yes, but FOSUB relies on DIC option 
    430 Feb 03 12:12:57 <Stof>  rande's point was to extend the class without making them a DIC parameter 
    431 Feb 03 12:13:05 <rande> yep 
    432 Feb 03 12:13:19 <rande> Application 
    433 Feb 03 12:13:38 <rande> Application\Sonata\NewsBundle\Entity\Post 
    434 Feb 03 12:13:47 <rande> a global namespace ;) 
    435 Feb 03 12:13:52 <Stof>  but then, it would mean that extending the class is mandatory, even if you don't need to extend the model 
    436 Feb 03 12:14:10 <jmikola|w>     as well as making that directory structure, perhaps 
    437 Feb 03 12:14:47 <rande> Stof : not really, a bundle creator can choice to not use a mapped supper class 
    438 Feb 03 12:15:10 <Stof>  and then, how would you extend the model ? 
    439 Feb 03 12:15:19 <rande> jmikola|w: it is the purpose of EasyExtendBundle 
    440 Feb 03 12:15:29 <rande> Stof, in this case you can't 
    441 Feb 03 12:16:19 <Stof>  well, then the best practice should be the way FOSUB does as it give you a way to extend the User class without requiring a global namespace 
    442 Feb 03 12:16:30 <Stof>  using a DIC parameter 
    443 Feb 03 12:17:00 <Stof>  and this is up to the bundle dev 
    444 Feb 03 12:17:10 <Stof>  to make its bundle extensible 
    445 Feb 03 12:17:25 <rande> yes but by default it is not up to the dev 
    446 Feb 03 12:17:35 <rande> as any bundle can be extendable 
    447 Feb 03 12:17:52 <rande> unless we add a option Bundle::isExtendable 
    448 Feb 03 12:18:02 <Stof>  it can be extendable if it is designed this way 
    449 Feb 03 12:18:28 <Stof>  you just said that the model is extensible only when it uses mapped superclasses 
    450 Feb 03 12:18:32 <avalanche123>  the best practice is really not to extend classes that weren't designed for extension 
    451 Feb 03 12:18:40 <avalanche123>  and to wrap them and proxy to them yourself 
    452 Feb 03 12:18:41 <Stof>  so it is up to the dev to make it extensible 
    453 Feb 03 12:18:46 <avalanche123>  yes 
    454 Feb 03 12:19:06 <rande> avalanche123: agreed but for now it is not the case as any ressources can be extendable 
    455 Feb 03 12:19:27 <avalanche123>  rande, maybe that is the problem we need to fix then? 
    456 Feb 03 12:19:31 <naderman>      avalanche123: indeed the issue is that it's pretty much impossible to make anything fully extensible at all 
    457 Feb 03 12:19:39 *       cescalante is now known as ce_afk 
    458 Feb 03 12:19:41 <Stof>  model entities are not resources in Symfony2 
    459 Feb 03 12:19:57 <avalanche123>  naderman exactly 
    460 Feb 03 12:20:13 <rande> Stof : symfony allows to redefine : Controller, ressource and templates 
    461 Feb 03 12:20:31 <Stof>  and if you want to add stuff in a model which is not designed to be extensible, you can use composition instead of inheritance 
    462 Feb 03 12:20:34 <rande> why not the layer model ?(I know it is a doctrine issue) 
    463 Feb 03 12:20:54 <Stof>  rande: Controller are extensible *only* if they are defined as a service by the bundle dev 
    464 Feb 03 12:21:20 <avalanche123>  rande, symfony allows you to overload services *any services* 
    465 Feb 03 12:21:21 <Stof>  (unless you redefine the routing to point to your classes) 
    466 Feb 03 12:21:56 <avalanche123>  so maybe you should make the models you're interested in extending a service with scope prototype of instantiation and make its class a DIC parameter for retrieval? 
    467 Feb 03 12:21:59 <avalanche123>  rande ^ 
    468 Feb 03 12:22:39 <avalanche123>  *for instantiation 
    469 Feb 03 12:22:40 <rande> look to much stuff to do 
    470 Feb 03 12:22:40 <Stof>  templates and routing files are resources, controller may be services (and not resources) and entities are not resources either 
    471 Feb 03 12:22:40 <naderman>      avalanche123: the problem is with doctrine mappings of relationships 
    472 Feb 03 12:23:08 <naderman>      avalanche123: since you can't tell doctrine that an entity's actual name is in a DIC parameter 
    473 Feb 03 12:23:19 <rande> symfony user are not always php/oop expert ... 
    474 Feb 03 12:23:34 <avalanche123>  right, I understand the problems there, but its really domain we're talking about, its not easily extendable, while controllers and templates are just entry/exit points of application 
    475 Feb 03 12:24:05 <rande> I need to go 
    476 Feb 03 12:24:15 <avalanche123>  rande, cya 
    477 Feb 03 12:24:59 <avalanche123>  my opinion is only mine however and maybe we can come up with a proper solution for allowing extension and replacing models 
     11Feb 10 11:02:52 <Stof>  lsmith: meeting ? or do you want to wait ? 
     12Feb 10 11:03:10 <lsmith>        i guess we might as well start 
     13Feb 10 11:03:16 <lsmith>        not sure if he is traveling back today 
     14Feb 10 11:03:18 <lsmith>        or whatever 
     15Feb 10 11:03:41 <lsmith>        then again .. most of the topics seem to require his presence 
     16Feb 10 11:03:53 <Stof>  yes 
     17Feb 10 11:04:05 <lsmith>        skip bootstrap.php in app_dev.php: http://bit.ly/htff3I 
     18Feb 10 11:04:10 <lsmith>        maybe that can be discussed .. 
     19Feb 10 11:04:16 <lsmith>        it should just be a small pull for the sandbox 
     20Feb 10 11:04:27 <lsmith>        anyone else around? 
     21Feb 10 11:04:37 <lsmith>        jmikola, kriswallsmith, Seldaek? 
     22Feb 10 11:04:46 <Seldaek>       yup 
     23Feb 10 11:05:11 <mvrhov>        what's interesting is that, I wasn't weven using bootstrap.php.. if it wasn't for your email I'd probably forget about it 
     24Feb 10 11:05:11 <Seldaek>       bootstrap, I'm with you on that one 
     25Feb 10 11:05:41 <Stof>  well, this would mean having a bootstrap_dev.php which require the autoloader and the autoload.php file 
     26Feb 10 11:05:52 <lsmith>        yeah 
     27Feb 10 11:05:53 <Stof>  instead of requiring the Symfony bootstrap file 
     28Feb 10 11:06:04 <Stof>  but I think it is a good idea 
     29Feb 10 11:06:20 <lsmith>        not sure why i didnt just make a pull request 
     30Feb 10 11:06:48 <lsmith>        hmm rande is also not around 
     31Feb 10 11:06:56 <lsmith>        johanness: ping 
     32Feb 10 11:07:47 <jmikola|w>     lsmith: hi 
     33Feb 10 11:07:54 <jmikola|w>     oh snap, meeting time 
     34Feb 10 11:08:02 <jmikola|w>     i think lots of people are travelling  
     35Feb 10 11:08:07 <lsmith>        yeah 
     36Feb 10 11:09:47 <lsmith>        well i am not sure if we are having a meeting at all 
     37Feb 10 11:10:07 <jmikola|w>     i would suggest bumping to friday, but realized that's like 5pm for you european folks :) 
     38Feb 10 11:10:18 <johnwards>     Beer O'clock 
     39Feb 10 11:10:26 <fabian>        stzbr! 
     40Feb 10 11:10:37 *       henrikbjorn has quit (Remote host closed the connection) 
     41Feb 10 11:10:42 <Stof>  is there any subject which does not require fabpot's presence ? 
     42Feb 10 11:10:49 <lsmith>        fabian: now you have to explain stzbr to the uninitiated :) 
     43Feb 10 11:11:10 <lsmith>        well we could try to push a topic forward 
     44Feb 10 11:11:17 <lsmith>        like Eager Response Creation: http://bit.ly/f3FskB 
     45Feb 10 11:11:23 <lsmith>        which is still in the early thought stages 
     46Feb 10 11:11:33 <lsmith>        but johanness doesnt seem to be around 
     47Feb 10 11:11:47 *       notjosh (~notjosh@S0106001d60439f63.vc.shawcable.net) has joined #symfony-dev 
     48Feb 10 11:12:32 <Stof>  well, if we need the presence of other peoples for all subjects, the meeting seems like being a fail today 
     49Feb 10 11:12:51 <jmikola|w>     re: eager response creation, when a controller could have several exit paths, returning redirects, forwards or rendered templates, those would all capitalize on the same response object? 
     50Feb 10 11:13:03 <lsmith>        jmikola|w: yes 
     51Feb 10 11:13:30 *       Herzult (~Herzult@ip-22.net-89-2-70.rev.numericable.fr) has left #symfony-dev 
     52Feb 10 11:13:31 <lsmith>        the main reason to do this is for listeners that happen before the controller 
     53Feb 10 11:13:33 *       Herzult (~Herzult@ip-22.net-89-2-70.rev.numericable.fr) has joined #symfony-dev 
     54Feb 10 11:13:40 <jmikola|w>     which need to alter the response 
     55Feb 10 11:13:46 <lsmith>        yeah 
     56Feb 10 11:14:12 <lsmith>        with scoping in place now .. 
     57Feb 10 11:14:21 <Seldaek>       it might also fix the fact that right now, the response is in the  prototype scope 
     58Feb 10 11:14:22 <lsmith>        it doesnt seem such a bad idea anymore 
     59Feb 10 11:14:27 <Seldaek>       which honestly is .. I don't know what 
     60Feb 10 11:14:38 <jmikola|w>     Seldaek: that's just using the container as a respone factory :) 
     61Feb 10 11:14:42 <lsmith>        Seldaek: protoype means that you get a fresh instance everytime 
     62Feb 10 11:14:51 <jmikola|w>     per the mailing list, i think the big objection was if request contained a response, is that true? 
     63Feb 10 11:14:59 <Seldaek>       yeah ok, but it should be in the request scope imo 
     64Feb 10 11:15:16 <lsmith>        Seldaek: thats essentially what johanness was proposing 
     65Feb 10 11:15:20 <lsmith>        if its in the request scope 
     66Feb 10 11:15:30 <lsmith>        listeners could make an instance and set stuff on the response 
     67Feb 10 11:15:40 <lsmith>        and when the controller then gets the response 
     68Feb 10 11:15:43 <jmikola|w>     the only thing i can think of if we share a response object in that scope, we might want a method to essentially reset the response 
     69Feb 10 11:15:45 <lsmith>        it would already have stuff set on it 
     70Feb 10 11:16:05 <Stof>  jmikola|w: why resetting the response ? 
     71Feb 10 11:16:31 <jmikola|w>     just thinking how the redirect() convenience methods both sets the location header and content for a meta html redirect 
     72Feb 10 11:16:55 <lsmith>        jmikola|w: sure a reset() might be ok .. 
     73Feb 10 11:17:00 <jmikola|w>     maybe someone has a listener that will set the location header but forget to erase or reset the content 
     74Feb 10 11:17:20 <jmikola|w>     wouldn't really matter if the response code was a 3xx, of course - just thinking aloud 
     75Feb 10 11:17:23 <lsmith>        for the rare cases that you think you need to start over 
     76Feb 10 11:17:53 <lsmith>        do we see any real use case for multiple response instances inside a single (sub)request? 
     77Feb 10 11:17:55 *       gordonslondon has quit (Read error: Connection reset by peer) 
     78Feb 10 11:17:58 <jmikola|w>     i think initially, it would make it easy for people to port over code that currently constructs new responses 
     79Feb 10 11:18:03 *       gordonslondon (~julesbous@ble59-5-82-233-204-65.fbx.proxad.net) has joined #symfony-dev 
     80Feb 10 11:18:33 *       gordonslondon has quit (Read error: No route to host) 
     81Feb 10 11:18:35 <jmikola|w>     ultimately, a request is only going to result in a single response, whether it's sub or master - i can't think of a reason to have multiple responses 
     82Feb 10 11:18:37 *       gordonslondon (~julesbous@ble59-5-82-233-204-65.fbx.proxad.net) has joined #symfony-dev 
     83Feb 10 11:18:57 <Stof>  I can't neither 
     84Feb 10 11:19:09 <lsmith>        so then its settled :) 
     85Feb 10 11:19:27 <jmikola|w>     there's no pull request for this yet, correct? just ML discussion 
     86Feb 10 11:19:28 <lsmith>        also for the rare case where for some obscure reason you think you do need multiple response's 
     87Feb 10 11:19:40 *       rooster has quit (Remote host closed the connection) 
     88Feb 10 11:19:41 <lsmith>        you can just inherit the default service and set a different scope 
     89Feb 10 11:19:58 <lsmith>        jmikola|w: the pull request is insanley trivial .. change the scope 
     90Feb 10 11:20:09 <lsmith>        well then a couple of listeners could be simplified 
     91Feb 10 11:23:27 <johnwards>     Meeting over? 
     92Feb 10 11:23:39 <lsmith>        johnwards: ask away :) 
     93Feb 10 11:23:52 <unknownbliss>  never started did it? 
     94Feb 10 11:24:12 <Stof>  unknownbliss: well, we discussed two of the points 
     95Feb 10 11:24:26 <Stof>  but most devs are not there today 
    47896}}}