IRCLogs20110203 (diff)

You must first sign up to be able to contribute.

Changes between Version 4 and Version 5 of IRCLogs20110203

lsmith (IP:
02/14/11 22:39:09 (7 years ago)

restored original version


  • IRCLogs20110203

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