You must first sign up to be able to contribute.

Version 5 (modified by lsmith, 7 years ago)
restored original version


RFC and update on Extension refactoring

Recent Form refactoring

Coordinating SFLive Hackday

Adding the view layer

[RFC] Config validation compiler pass

Third-party dependencies in Components

The directory structure does not work for model

IRC logs

Feb 03 11:01:18 <lsmith>	ok .. lets start the meeting
Feb 03 11:01:38 *	jonwage ( has joined #symfony-dev
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
Feb 03 11:01:54 <lsmith>	i think that is probably sufficient .. and safes me the work writing a summary
Feb 03 11:01:58 *	ajessu ( has joined #symfony-dev
Feb 03 11:02:23 <lsmith>	first topic .. RFC and update on Extension refactoring Options:
Feb 03 11:02:26 *	becky ( has joined #symfony-dev
Feb 03 11:02:30 <lsmith>	jmikola|w, weaverryan?
Feb 03 11:02:45 *	bobthecow (~bobthecow@unaffiliated/bobthecow) has left #symfony-dev
Feb 03 11:02:47 <jmikola|w>	sure
Feb 03 11:03:06 <weaverryan>	hit it - I'm here now too
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
Feb 03 11:03:26 *	bobthecow (~bobthecow@unaffiliated/bobthecow) has joined #symfony-dev
Feb 03 11:03:33 <lsmith>	bschussek: are you around? next topic would be your recent refactorings
Feb 03 11:03:34 <jmikola|w>	his mailing list post from last night revealed the implementation with respect to security extension
Feb 03 11:03:39 <bschussek>	sure
Feb 03 11:04:09 <lsmith>
Feb 03 11:04:23 *	ndusan has quit (Quit: ndusan)
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
Feb 03 11:04:44 <lsmith>	jmikola|w: this change hasnt been pulled yet ... has it?
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
Feb 03 11:05:10 <jmikola|w>	lsmith: it actually may have, i don't see any open pulls from johanness  on symfony
Feb 03 11:05:23 <lsmith>	i never saw a pull for it ..
Feb 03 11:05:35 <jmikola|w>	oh, perhaps it's just in his personal fork then
Feb 03 11:05:35 <weaverryan>	I think the system itself has been merged in
Feb 03 11:05:44 <lsmith>	yup .. points nowhere
Feb 03 11:05:52 <jmikola|w>	johanness had a lot of "wip" commits to his fork yesterday for this :)
Feb 03 11:06:05 <lsmith>	so you 3 agree that this is easy to understand, maintainable and covers all the cases?
Feb 03 11:06:07 *	ornicar (~ornicar@ has joined #symfony-dev
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
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)
Feb 03 11:06:29 <weaverryan>	the merging, validation, and normalization would take place elsewhere
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
Feb 03 11:06:40 <johanness>	the normalization has been merged
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 :)
Feb 03 11:07:18 <weaverryan>	johanness: are the "default" values specified via this method or in a different way?
Feb 03 11:07:41 <johanness>	weaverryan, they are attached to the nodes for scalars, ->defValue($value)
Feb 03 11:07:51 <johanness>	arrays cannot have defaults
Feb 03 11:08:09 <jmikola|w>	johanness: by that you mean things like "options" arrays?
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
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?
Feb 03 11:08:46 <johanness>	weaverryan, that's not possible since you can have a dynamic number of elements in an array
Feb 03 11:08:57 <johanness>	adding defaults must therefore be done at the end
Feb 03 11:09:04 <johanness>	when the entire structure of the config is known
Feb 03 11:09:11 <jmikola|w>	lsmith: these defaults are a bit different than the default params in DIC configs
Feb 03 11:09:23 <jmikola|w>	these are more like defaults if you just load your extension with ~ in yaml
Feb 03 11:09:32 <johanness>	lsmith, i've started to move defaults into the configuration class yes
Feb 03 11:09:59 <lsmith>	what gets me with all of this is that its now very hard to to figure out defaults
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
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
Feb 03 11:10:14 <jmikola|w>	i know that was a concern of yours from saturday
Feb 03 11:10:19 <lsmith>	i guess it would then require us to ensure that there is documentation for the defaults
Feb 03 11:10:22 <lsmith>	independent of the code
Feb 03 11:10:38 <lsmith>	previously in theory the DIC config's served as documentation on the defaults
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
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?
Feb 03 11:12:02 <weaverryan>	hmm
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
Feb 03 11:12:13 <johanness>	in my schema yes, that's basically what the prototype() is used for
Feb 03 11:12:23 <jmikola|w>	although simple options (not under dynamic keys) are arguably more clear in static yaml :)
Feb 03 11:12:33 <weaverryan>	I'm not convinced yet - but I need to look into it more
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
Feb 03 11:12:56 *	tecbot ( has joined #symfony-dev
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)
Feb 03 11:13:12 <jmikola|w>	weaverryan: what would the array be indexed by though? 
Feb 03 11:13:15 <lsmith>	weaverryan: yeah .. exactly
Feb 03 11:13:30 <jmikola|w>	it'd have to be some reserved key for such purposes, like _prototype: 
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 :)
Feb 03 11:13:41 <jmikola|w>	thinking  both about security firewalls and your doctrine connections
Feb 03 11:13:49 <jmikola|w>	i think they're quite similar in that respect
Feb 03 11:14:11 <weaverryan>	connections: []
Feb 03 11:14:13 <jmikola|w>	firewalls is a collection of structured config sub-trees... just with dynamic keys
Feb 03 11:14:16 <weaverryan>	connection_default: []
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
Feb 03 11:14:39 <weaverryan>	*maybe*
Feb 03 11:14:45 <lsmith>	anyway .. we are approaching the end of the timebox
Feb 03 11:14:48 <weaverryan>	I just really think we should work toward getting defaults into YAML
Feb 03 11:14:51 <johanness>	you could ofc load your defaults from a config file before passing them to ->defValue()
Feb 03 11:14:58 <weaverryan>	that's ok - I need to do more research anyways
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
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
Feb 03 11:15:08 <avalanche123>	weaverryan +1 on defaults in YAML
Feb 03 11:15:17 <bschussek>	weaverryan +1
Feb 03 11:15:56 <jmikola|w>	lsmith: i guess we can move on
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
Feb 03 11:16:07 <lsmith>	Recent Form refactoring:
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()
Feb 03 11:16:10 <lsmith>	bschussek ?
Feb 03 11:16:35 <bschussek>	I have simplified Form construction to reduce a number of bugs
Feb 03 11:16:54 <bschussek>	I won't go into much detail, but the documentation can be found here
Feb 03 11:17:06 <bschussek>	I have updated it and will update the rest in the following weeks
Feb 03 11:17:33 <bschussek>	the doc will encourage creating custom Form classes as best practice
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
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
Feb 03 11:18:15 <lsmith>	just to show an example:
Feb 03 11:18:16 <bschussek>	questions?
Feb 03 11:18:16 <lsmith>
Feb 03 11:18:38 <lsmith>
Feb 03 11:18:46 <lsmith>	would be nice to be able to set the validation groups inside the controller
Feb 03 11:18:58 <lsmith>	so if anyone has time .. would be great :)
Feb 03 11:19:03 <bschussek>	I agree. I don't think we have much to discuss here though
Feb 03 11:19:22 <lsmith>	btw .. the UserBundle has been updated with the new approach
Feb 03 11:19:26 <jmikola|w>	kriswallsmith: did you talk to bschussek about wanting to bind non-POST stuff to a form?
Feb 03 11:19:31 <lsmith>	so this can be used to play around if needed
Feb 03 11:19:40 <bschussek>	jmikola|w: I'm aware of this problem
Feb 03 11:19:47 <jmikola|w>	avalanche123: and you had concerns about supporting methods other than POST for API/Rest concerns
Feb 03 11:19:50 <bschussek>	my approach to fix this is to add a "method" option to Form
Feb 03 11:19:57 <bschussek>	the questions are:
Feb 03 11:20:09 <bschussek>	1. where do we get data from for PUT requests?
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
Feb 03 11:20:21 <avalanche123>	indeed, I had concerns, and I don't think form should even care about the method
Feb 03 11:20:24 <jmikola|w>	as he was implementing something like sf1 admin generator filters, which store their state in session
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?
Feb 03 11:20:37 <avalanche123>	bschussek, let them populate Request::$request and form use that to perform binding
Feb 03 11:20:59 <bschussek>	avalanche123: ok, you would have to talk to Fabien about that
Feb 03 11:21:03 <bschussek>	question 2 remains
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
Feb 03 11:21:28 <bschussek>	jmikola|w: no it isn't. bind() in reality is just a shortcut method
Feb 03 11:21:37 <bschussek>	you can copy the code into your application and customize it
Feb 03 11:21:51 <bschussek>	setData(), submit() and validate() are all public
Feb 03 11:22:39 <bschussek>	any solution to question 2?
Feb 03 11:22:59 <jmikola|w>	re: #2, is that for auto-binding?
Feb 03 11:23:03 <bschussek>	yes
Feb 03 11:23:12 <mvrhov>	we don't autobind in that case?
Feb 03 11:23:20 <kriswallsmith>	auto-binding?
Feb 03 11:23:32 <jmikola|w>	what is the use case for such a thing?
Feb 03 11:23:36 <bschussek>	kriswallsmith: bind() reads the request method and decides whether a form was submitted or not
Feb 03 11:23:39 *	webPragmatist ( has joined #symfony-dev
Feb 03 11:23:42 <jmikola|w>	i wasn't aware posts are auto-bound
Feb 03 11:23:43 *	webPragmatist has quit (Changing host)
Feb 03 11:23:43 *	webPragmatist (~webby@unaffiliated/webpragmatist) has joined #symfony-dev
Feb 03 11:23:44 <bschussek>	for a GET request, this decision is not able
Feb 03 11:23:53 <bschussek>	-able -easy
Feb 03 11:23:56 <kriswallsmith>	what is the benefit of this?
Feb 03 11:23:57 <bschussek>	+easy
Feb 03 11:23:59 <bschussek>	sorry
Feb 03 11:24:03 <bschussek>	kriswallsmith: less code to write
Feb 03 11:24:23 <kriswallsmith>	um, i read that as "magic" ;)
Feb 03 11:24:31 <avalanche123>	+1 on magic
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
Feb 03 11:24:45 <jmikola|w>	bschussek: the user still has to call bind() themselves, even for GET, right?
Feb 03 11:24:45 <kriswallsmith>	less magic, more explicit
Feb 03 11:24:49 <bschussek>	and 90% where default cases
Feb 03 11:25:13 <kriswallsmith>	how do you disable auto-binding?
Feb 03 11:25:21 <bschussek>	kriswallsmith: by doing everything manually
Feb 03 11:25:26 <jmikola|w>	could there be an extra parameter that choses the Request property to bind from, defaulting to "request" ?
Feb 03 11:25:29 <bschussek>	i.e., calling submit()
Feb 03 11:25:32 <bschussek>	and passing the parameters
Feb 03 11:25:45 <bschussek>	jmikola|w: this extra parameter equals the form name
Feb 03 11:25:48 <kriswallsmith>	how does that disable auto-binding?
Feb 03 11:25:48 <lsmith>	5 more minutes in this timebox
Feb 03 11:25:56 <kriswallsmith>	i'll take a look at the code
Feb 03 11:26:01 <bschussek>	kriswallsmith: do that
Feb 03 11:26:01 <kriswallsmith>	but auto-binding sounds too magic to me
Feb 03 11:26:04 <bschussek>	there is nothing automatic
Feb 03 11:26:08 <bschussek>	just one shortcut method
Feb 03 11:26:16 <kriswallsmith>	ok
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
Feb 03 11:26:28 <jmikola|w>	you'd just want to use query instead
Feb 03 11:26:31 *	nielsie has quit (Ping timeout: 250 seconds)
Feb 03 11:26:39 <bschussek>	jmikola|w: yes, we can do that in bind()
Feb 03 11:26:44 <lsmith>	bschussek: "auto binding" is calling bind() and not auto binding is calling 3 methods
Feb 03 11:26:51 <bschussek>	lsmith: exactloy
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
Feb 03 11:27:07 <kriswallsmith>	i see, i thought bind was "calling itself"
Feb 03 11:27:17 <jmikola|w>	bschussek: perhaps there can be a "strategy" option of sorts
Feb 03 11:27:19 <bschussek>	maybe an important informatoin:
Feb 03 11:27:20 <lsmith>	so its manual .. just bind() is a helper that handles most of the cases
Feb 03 11:27:21 <jmikola|w>	by default, it's request+files
Feb 03 11:27:34 <bschussek>	the old bind() (i.e. pulling the request parameters into the form) is now called submit()
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
Feb 03 11:28:12 <jmikola|w>	and it also generates the array to pass to submit()
Feb 03 11:28:17 <bschussek>	exactly
Feb 03 11:28:54 *	dbenjamin has quit (*.net *.split)
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
Feb 03 11:29:12 <bschussek>	strategy?
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
Feb 03 11:29:23 <bschussek>	lsmith: exactly
Feb 03 11:29:47 <bschussek>	is it enough to check whether a query parameter with the form's name is available?
Feb 03 11:29:47 <jmikola|w>	bschussek: current behavior as i see it is:  array('request', 'files')
Feb 03 11:30:01 <bschussek>	jmikola|w: sure, but GET is not implemented if you look
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
Feb 03 11:30:04 <lsmith>	true
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
Feb 03 11:30:22 <bschussek>	yes
Feb 03 11:30:29 <jmikola|w>	so GET should certainly do that... but also ensure it's a GET method, no?
Feb 03 11:30:31 <lsmith>	ok .. we have reached the end of the timebox
Feb 03 11:30:35 <bschussek>	yes
Feb 03 11:30:39 <bschussek>	let's go with this solution
Feb 03 11:30:44 <bschussek>	if there are drawbacks, we'll discover
Feb 03 11:30:46 <lsmith>	Coordinating SFLive Hackday:
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
Feb 03 11:31:29 <lsmith>	now i am not sure if there is anyone who is attending SF around tonight?
Feb 03 11:31:31 <lsmith>	i guess kriswallsmith
Feb 03 11:31:36 <naderman>	I'm here too
Feb 03 11:31:39 <pgodel_work>	I walso wanted to know what was the plan in SF, but fabpot is not here
Feb 03 11:31:52 <lsmith>	what i was wondering about is we have johanness and bschussek who are responsible for some parts
Feb 03 11:31:55 <lsmith>	but what about others?
Feb 03 11:32:11 <kriswallsmith>	i arrive wednesday afternoon
Feb 03 11:32:11 <lsmith>	also i think one group of people needs to run static code analyizers over the code
Feb 03 11:32:19 <bschussek>	lsmith: +1
Feb 03 11:32:24 <lsmith>	i did this a bit .. and found a ton of screwed up use statements and missing variables
Feb 03 11:32:39 <pgodel_work>	lsmith: ok
Feb 03 11:32:40 <lsmith>	though its a bit tedious work .. since the analyzers i tried all gave about 70% false positives
Feb 03 11:32:53 <pgodel_work>	ouch
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
Feb 03 11:33:19 <lsmith>	jmikola|w: the rest is inside my phpStorm IDE .. and it also is a lot of work
Feb 03 11:33:29 <lsmith>	because there are just too many files to just scan all of Symfony
Feb 03 11:33:31 <naderman>	I assume we'll be on IRC during the hackdays so can also coordinate stuff in here
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
Feb 03 11:33:37 <lsmith>	so it would need to be done by separate teams of people
Feb 03 11:33:51 <lsmith>	it just sucks if we waste half of the saturday trying to get organized
Feb 03 11:34:18 <naderman>	lsmith: well is there someone who wants to help but doesn't know what to do?
Feb 03 11:34:30 <lsmith>	naderman: i am sure there will be quite a few
Feb 03 11:34:41 <bschussek>	lsmith: what about collecting open tasks?
Feb 03 11:34:46 <pgodel_work>	who is going to be there on sat and sun ?
Feb 03 11:34:55 <lsmith>	we have a few people coming to Zurich
Feb 03 11:35:01 <bschussek>	I am in Z├╝rich
Feb 03 11:35:02 <naderman>	so indeed I think we should just collect tasks for those on the mailinglist
Feb 03 11:35:05 <jmikola|w>	bschussek: lsmith did do a good job at rounding through old ML posts this week :)
Feb 03 11:35:13 <naderman>	if anyone can think of anything that could be done during hackdays post it?
Feb 03 11:35:14 <lsmith>	i think static code analysis, going through open tickets are two areas
Feb 03 11:35:33 <jmikola|w>	if johanness' config normalizer is good to go, that would be a great task as well
Feb 03 11:35:37 <lsmith>	ok .. so please everyone post topics
Feb 03 11:35:42 <jmikola|w>	to knock out some extensions over the weekend
Feb 03 11:35:43 <lsmith>	or better yet .. i will create a wiki page
Feb 03 11:35:44 <pgodel_work>	naderman: I was expecting fabien to do that
Feb 03 11:35:49 <lsmith>	after the meeting
Feb 03 11:35:51 <naderman>	pgodel_work: me too, kind of
Feb 03 11:35:53 <lsmith>	and people add stuf there
Feb 03 11:36:00 <pgodel_work>	but yes, we should know ahead of time to not waste time
Feb 03 11:36:05 <bschussek>	I have a couple of open Form/Validator tickets on
Feb 03 11:36:12 <lsmith>	i will try to coordinate stuff then
Feb 03 11:36:13 <bschussek>	so if there are too many bored people, they can help me :)
Feb 03 11:36:15 <lsmith>	as good as i can
Feb 03 11:36:22 <lsmith>	maybe i can get a hold of fabien tomorrow to discuss stuff
Feb 03 11:36:45 <lsmith>	ok?
Feb 03 11:36:48 <pgodel_work>	a wiki or a google doc for online collaboration would be very useful
Feb 03 11:36:48 <bschussek>	+1
Feb 03 11:36:48 <jmikola|w>	bschussek: is that replacing trac?
Feb 03 11:36:52 <jmikola|w>	or is it your personal tool
Feb 03 11:36:59 <lsmith>	pgodel_work: yeah i will put it on trac
Feb 03 11:37:01 <bschussek>	jmikola|w: my personal one, because trac sucks
Feb 03 11:37:31 <lsmith>	ok .. next topic then
Feb 03 11:37:33 <pgodel_work>	we also need to know what times
Feb 03 11:37:44 <pgodel_work>	this is going to be to coordinate local and remote people
Feb 03 11:37:46 <lsmith>	well zurich will be ahead of SF by quite a bit :)
Feb 03 11:37:54 <pgodel_work>	yup
Feb 03 11:38:22 <lsmith>	we have a lot of maybe's for Zurich ..
Feb 03 11:38:27 <lsmith>	will see who shows up
Feb 03 11:38:38 <lsmith>	anyway .. like i said .. i will create a wiki page
Feb 03 11:38:46 <pgodel_work>	good
Feb 03 11:38:48 <lsmith>	please add topics there, or send them to the mailinglist
Feb 03 11:38:50 <lsmith>	or ping me
Feb 03 11:38:55 <lsmith>	i will try to keep the wiki page organized
Feb 03 11:39:02 <lsmith>	moving on then ..
Feb 03 11:39:19 <lsmith>	uhm .. so next topic is Adding the view layer:
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
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
Feb 03 11:40:05 <naderman>	I'm not sure what Fabien's problem with an html encoder was
Feb 03 11:40:07 <mvrhov>	1st one is 404
Feb 03 11:40:12 *	ornicar has quit (Quit: WeeChat 0.3.4)
Feb 03 11:40:19 <naderman>	semantically that is exactly correct
Feb 03 11:40:21 <mvrhov>	1st link
Feb 03 11:40:23 <lsmith>	mvrhov: ah sorry ..
Feb 03 11:40:27 <lsmith>	its now all merged to master
Feb 03 11:40:32 <lsmith>
Feb 03 11:40:38 *	rooster has quit (Remote host closed the connection)
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
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
Feb 03 11:41:07 <lsmith>	and then we deliver that
Feb 03 11:41:17 <lsmith>	and implement the view .. and then we are told that we shouldnt use it for html
Feb 03 11:41:20 <naderman>	and HTML is just one of those more specific ones
Feb 03 11:41:24 <lsmith>	which sort of made the entire thing pointless
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
Feb 03 11:42:27 <naderman>	will do in SF
Feb 03 11:42:34 <lsmith>	ok next topic then ..
Feb 03 11:42:47 <lsmith>	[RFC] Config validation compiler pass:
Feb 03 11:42:57 <lsmith>	if i read this properly .. johanness said its already solved?
Feb 03 11:43:05 <lsmith>	by the synthetic attribute?
Feb 03 11:43:35 <jmikola|w>	i believe that was it from the ML post
Feb 03 11:44:35 <lsmith>	ok .. anyone have questions on this?
Feb 03 11:44:37 <lsmith>	otherwise moving on
Feb 03 11:44:41 <jmikola|w>	he said synthetic makes it possible, but it needs an addition to ResolveInvalidReferencesPass
Feb 03 11:45:16 <lsmith>	Third-party dependencies in Components Options:
Feb 03 11:45:37 <lsmith>	i guess this topic wasnt quote over for some
Feb 03 11:45:51 <lsmith>	then again none of the people unhappy seem to be around today
Feb 03 11:46:14 <lsmith>	so ..
Feb 03 11:46:25 <lsmith>	i guess there is nothing to discuss further ..
Feb 03 11:46:32 <lsmith>	ah no
Feb 03 11:46:39 <lsmith>	The directory structure does not work for model Options:
Feb 03 11:46:46 <lsmith>	i didnt have time to read up this thread myself yet
Feb 03 11:46:57 <lsmith>	not sure if there is anything left open
Feb 03 11:47:14 <rande>	well ...
Feb 03 11:47:23 <jmikola|w>	lsmith: i have one more topic if you want to throw it out there
Feb 03 11:47:31 <rande>	it is more about how people want to use bundle
Feb 03 11:47:40 <jmikola|w>	but i think the dir structure was rande's topic :)
Feb 03 11:47:54 <rande>	and how they can extend model from this bundle
Feb 03 11:47:59 <rande>	jmikola: yep
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
Feb 03 11:48:05 *	igorw (~igorw@phpbb/developer/evil3) has joined #symfony-dev
Feb 03 11:48:11 <rande>	rande = th0masr = Thomas R.
Feb 03 11:48:15 <jmikola|w>	akin to how templates would be overridden?
Feb 03 11:48:45 <rande>	all ressources can be overridden
Feb 03 11:48:57 <rande>	controller, routing, templates
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.
Feb 03 11:49:00 <rande>	but not Model
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
Feb 03 11:49:07 <rande>	look weird to be
Feb 03 11:49:18 <rande>	to me
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)
Feb 03 11:50:30 <rande>	Stof: I can apply your remark to bundle
Feb 03 11:50:50 <rande>	why a bundle should be extendable ?
Feb 03 11:51:15 <jmikola|w>	Stof: i think there's good reason that controllers for extensible bundles should be services
Feb 03 11:51:16 <rande>	the current implementation allows devs to reimplement/extends some parts
Feb 03 11:51:29 <jmikola|w>	but i'd argue controllers themselves aren't very extensible to begin with :)
Feb 03 11:51:33 <rande>	option 1 : remove this option
Feb 03 11:51:45 <rande>	option 2: make all elements extendable
Feb 03 11:52:06 <naderman>	option 3: make/keep the ones extensible for which it works well
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
Feb 03 11:52:18 <naderman>	I'm really not sure what exactly you are looking for
Feb 03 11:52:22 <kriswallsmith>	you may be able to use the doctrine namespace alias mechanism
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?
Feb 03 11:52:34 <kriswallsmith>	but that would require copying all model classes
Feb 03 11:52:35 <jmikola|w>	you're under no obligation to extend the base class, just implement the interface really
Feb 03 11:52:54 <kriswallsmith>	rande: composition is probably the way to go
Feb 03 11:52:56 <rande>	the issue about that is how do you use model constant ?
Feb 03 11:53:13 <jmikola|w>	what's "model constant"?
Feb 03 11:53:26 <rande>	const STATUS_OK = 1
Feb 03 11:53:39 <naderman>	what is the issue
Feb 03 11:53:51 <jmikola|w>	for that, you could easily refer to the bundle's model class, no?
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)
Feb 03 11:54:23 <naderman>	Stof: hmm that is indeed something that would be nice to change
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
Feb 03 11:54:29 <jmikola|w>	based on the configured classes 
Feb 03 11:54:32 <rande>	if you have a global namespace there is no problem
Feb 03 11:54:43 <jmikola|w>	that would move the relationship config out of mappings and into the extension's PHP
Feb 03 11:54:54 <rande>	I don't want to declare all the class in the DIC configuration
Feb 03 11:55:03 <rande>	image a project with 100 classes
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
Feb 03 11:55:32 <Stof>	naderman: the issue is that the mapping needs to contain the FQCN of the target entity
Feb 03 11:55:40 <naderman>	yes I realise that
Feb 03 11:55:53 <jmikola|w>	kriswallsmith: does doctrine have namespace aliases for such a thing?   aliases used for mappings?
Feb 03 11:56:00 <rande>	now the UserBundle:User does not works with association definition
Feb 03 11:56:18 <kriswallsmith>	rande: ah, good point
Feb 03 11:56:21 <Stof>	rande: of course, the mapping is Doctrine stuff, not Symfony one
Feb 03 11:56:35 <rande>	that why we need to use a global namesapce
Feb 03 11:56:57 <rande>	is the only easy way to share and extends model
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
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
Feb 03 11:57:40 <rande>	naderman: is is possible to redifine the mapping at runtime
Feb 03 11:57:43 <Stof>	rande: extending the model is impossible with the way the mapping works
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
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 
Feb 03 11:58:18 <jmikola|w>	obviously for 100 classes it'd be a nightmare :)
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
Feb 03 11:58:40 <naderman>	right, well I'd be interested in seeing that in the UserBundle
Feb 03 11:58:49 <Stof>	yeah, but where do you define the relations ?
Feb 03 11:59:06 <jmikola|w>	they'd have to be in the application version i'd think
Feb 03 11:59:26 <rande>
Feb 03 11:59:30 <Stof>	thus, defining toMany relations in a mapped superclass breaks things if you have several entities extending it
Feb 03 11:59:32 <naderman>	is there some way to make the DoctrineBundle resolve references to entities?
Feb 03 12:00:02 <naderman>	so you could define them referencing an option instead of the actual FQCN
Feb 03 12:00:11 <rande>	extending in not the correct term
Feb 03 12:00:21 <Stof>	rande: providing mapping for classes outside the bundle seems really weird
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
Feb 03 12:01:08 <lsmith>	ok meeting time is officially over .. but feel free to continue :)
Feb 03 12:01:12 <rande>	Stof : waht should be the good trade off ?
Feb 03 12:01:16 *	ornicar (~ornicar@ has joined #symfony-dev
Feb 03 12:01:22 <Stof>	so this means distributing broken code
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?
Feb 03 12:01:45 <jmikola|w>	lsmith: i did shortly before our meeting
Feb 03 12:01:52 <jmikola|w>	hopefully i gets merged into fabpot/master before then though :)
Feb 03 12:01:55 <lsmith>	jmikola|w: ah ok
Feb 03 12:01:56 <rande>	Stof : I use
Feb 03 12:02:11 <jmikola|w>	please comment on the ML if you have an opinion, though
Feb 03 12:02:24 <Stof>	yeah, but the project is in a broken state when you boot it to run the command
Feb 03 12:02:32 <rande>	the bundle just create a full valid hierarchie in the Application namespace
Feb 03 12:02:45 <Stof>	so this means that all bundles needs to be able to boot in a broken state
Feb 03 12:02:54 <rande>	yes
Feb 03 12:03:16 <rande>
Feb 03 12:03:33 <rande>	it is how I solve the issue in the UserBundle
Feb 03 12:03:42 <rande>	class_exists!
Feb 03 12:03:56 <rande>	I don't this solution is the best or ideal
Feb 03 12:04:01 <rande>	it's just working
Feb 03 12:04:12 <Stof>	yeah, so then, you will have no exception if you don't create the class
Feb 03 12:04:15 <rande>	I can extends model at the Application layer
Feb 03 12:04:33 <Stof>	and you will not know that your project is in a broken state
Feb 03 12:04:47 <rande>	Stof : correct
Feb 03 12:05:02 <rande>	but a project is always broken
Feb 03 12:05:09 <rande>	you need to read the README file
Feb 03 12:05:17 <rande>	to know how to install bundle ...
Feb 03 12:05:24 <rande>	so it is a false problem
Feb 03 12:05:37 *	nic4m has quit (Read error: Operation timed out)
Feb 03 12:05:56 *	nic4m ( has joined #symfony-dev
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
Feb 03 12:06:24 <Stof>	rande: the issue is that EasyExtendBundle require to *boot* the kernel in a broken state
Feb 03 12:06:36 *	bschussek ( has left #symfony-dev
Feb 03 12:06:45 <rande>	Stof : I get your point, I know ...
Feb 03 12:07:06 <lsmith>	i think its definately a major issue atm
Feb 03 12:07:16 <rande>	but this can be achieve by creating a independant task
Feb 03 12:07:22 <lsmith>	didnt beberlei say that in 2.1 they attempt to solve the issue inside doctrine?
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
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
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
Feb 03 12:09:11 <rande>	these are issues but there are trivials
Feb 03 12:09:33 <rande>	the main thing is : "we" need an agreement
Feb 03 12:09:50 <rande>	is this solution should be a convention ?
Feb 03 12:09:57 <rande>	yes or no
Feb 03 12:10:25 <jmikola|w>	rande: any consensus on this should likely be added to the best practices for bundles
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
Feb 03 12:10:55 <rande>	jmikola|w: agreed
Feb 03 12:11:14 <rande>	Stof : I don't see complexity
Feb 03 12:11:27 <rande>	I use this solution with no pb
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
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
Feb 03 12:12:31 <Stof>	jmikola|w: yes, but FOSUB relies on DIC option
Feb 03 12:12:57 <Stof>	rande's point was to extend the class without making them a DIC parameter
Feb 03 12:13:05 <rande>	yep
Feb 03 12:13:19 <rande>	Application
Feb 03 12:13:38 <rande>	Application\Sonata\NewsBundle\Entity\Post
Feb 03 12:13:47 <rande>	a global namespace ;)
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
Feb 03 12:14:10 <jmikola|w>	as well as making that directory structure, perhaps
Feb 03 12:14:47 <rande>	Stof : not really, a bundle creator can choice to not use a mapped supper class
Feb 03 12:15:10 <Stof>	and then, how would you extend the model ?
Feb 03 12:15:19 <rande>	jmikola|w: it is the purpose of EasyExtendBundle
Feb 03 12:15:29 <rande>	Stof, in this case you can't
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
Feb 03 12:16:30 <Stof>	using a DIC parameter
Feb 03 12:17:00 <Stof>	and this is up to the bundle dev
Feb 03 12:17:10 <Stof>	to make its bundle extensible
Feb 03 12:17:25 <rande>	yes but by default it is not up to the dev
Feb 03 12:17:35 <rande>	as any bundle can be extendable
Feb 03 12:17:52 <rande>	unless we add a option Bundle::isExtendable
Feb 03 12:18:02 <Stof>	it can be extendable if it is designed this way
Feb 03 12:18:28 <Stof>	you just said that the model is extensible only when it uses mapped superclasses
Feb 03 12:18:32 <avalanche123>	the best practice is really not to extend classes that weren't designed for extension
Feb 03 12:18:40 <avalanche123>	and to wrap them and proxy to them yourself
Feb 03 12:18:41 <Stof>	so it is up to the dev to make it extensible
Feb 03 12:18:46 <avalanche123>	yes
Feb 03 12:19:06 <rande>	avalanche123: agreed but for now it is not the case as any ressources can be extendable
Feb 03 12:19:27 <avalanche123>	rande, maybe that is the problem we need to fix then?
Feb 03 12:19:31 <naderman>	avalanche123: indeed the issue is that it's pretty much impossible to make anything fully extensible at all
Feb 03 12:19:39 *	cescalante is now known as ce_afk
Feb 03 12:19:41 <Stof>	model entities are not resources in Symfony2
Feb 03 12:19:57 <avalanche123>	naderman exactly
Feb 03 12:20:13 <rande>	Stof : symfony allows to redefine : Controller, ressource and templates
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
Feb 03 12:20:34 <rande>	why not the layer model ?(I know it is a doctrine issue)
Feb 03 12:20:54 <Stof>	rande: Controller are extensible *only* if they are defined as a service by the bundle dev
Feb 03 12:21:20 <avalanche123>	rande, symfony allows you to overload services *any services*
Feb 03 12:21:21 <Stof>	(unless you redefine the routing to point to your classes)
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?
Feb 03 12:21:59 <avalanche123>	rande ^
Feb 03 12:22:39 <avalanche123>	*for instantiation
Feb 03 12:22:40 <rande>	look to much stuff to do
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
Feb 03 12:22:40 <naderman>	avalanche123: the problem is with doctrine mappings of relationships
Feb 03 12:23:08 <naderman>	avalanche123: since you can't tell doctrine that an entity's actual name is in a DIC parameter
Feb 03 12:23:19 <rande>	symfony user are not always php/oop expert ...
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
Feb 03 12:24:05 <rande>	I need to go
Feb 03 12:24:15 <avalanche123>	rande, cya
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