SprintSymfony12AdminGenerator: symfony-sprint.log

[2008-08-29 14::17:03] » You left the chat by being disconnected from the server.
[2008-08-29 14::20:22] » You rejoined the room.
[2008-08-29 14::20:50] lvanderree: you don't want to miss a word, it it
[2008-08-29 14::21:33] » chrisbur joined the chat room.
[2008-08-29 14::22:02] » silvain left the chat room.
[2008-08-29 14::22:15] » You left the chat by being disconnected from the server.
[2008-08-29 14::22:36] » You rejoined the room.
[2008-08-29 14::22:57] fabpot: NiKo` will takes notes during this session
[2008-08-29 14::23:28] lvanderree: ah nice
[2008-08-29 14::23:41] jvdlaan: k nice
[2008-08-29 14::27:53] » klemens_u left the chat room.
[2008-08-29 14::28:06] » klemens_u joined the chat room.
[2008-08-29 14::28:50] » bschussek joined the chat room.
[2008-08-29 14::28:56] lvanderree: there he is
[2008-08-29 14::29:07] bschussek: hi all
[2008-08-29 14::29:10] lvanderree: ola
[2008-08-29 14::30:10] fabpot: ok, François has left, but I'm still here
[2008-08-29 14::32:01] bschussek: I agree. A decoupled admin generator would also mean more flexibility in extending different parts of it
[2008-08-29 14::32:05] fabpot: We can have a .yml configuration file, but this is optional
[2008-08-29 14::32:30] klemens_u: good aproach.
[2008-08-29 14::32:40] fabpot: So, we need a main object for each object, something like ArticleAdmin, CommentAdmin, ...
[2008-08-29 14::32:40] lvanderree: I don't mind loosing the yml configuration, as long as it remains possible to do fast and flexible generation
[2008-08-29 14::33:08] fabpot: This ArticleAdmin extends sfAdmin and all the configuration can be done in this class
[2008-08-29 14::34:32] bschussek: sounds good to me. I don't like the YAML configuration anyway, as for customized pages becomes very big and unreadable
[2008-08-29 14::34:44] klemens_u: agree.
[2008-08-29 14::35:45] fabpot: When you think about it, and as far the UI is concerned, the admin geneartor is pretty simple: an object list, a filter object, a form object
[2008-08-29 14::35:47] lvanderree: that sounds good. So if I understand you correctly we get one object, for instance the ArticleAdmin-Object
[2008-08-29 14::35:52] fabpot: anything else I'm missing here?
[2008-08-29 14::35:52] synace: does sfAdmin extends sfActions?
[2008-08-29 14::36:05] fabpot: no, sfAdmin is independant of the controller
[2008-08-29 14::36:08] lvanderree: this Object is configured in a config-constructor, like you do in the sfForm-way
[2008-08-29 14::36:14] synace: fabpot, does this allow for inverse of the current approach (currently you extend your code on top of the generated module actions. by decoupling, you'll be able to add admin to an existing module)
[2008-08-29 14::36:23] fabpot: ok, this is yet another requirement, most the things must be decoupled from the controller and the templates
[2008-08-29 14::36:26] » NiKo` left the chat room.
[2008-08-29 14::36:36] fabpot: synace: exactly
[2008-08-29 14::36:57] synace: fabpot: good consistent w/ the rest of the 1.2 approach
[2008-08-29 14::37:09] lvanderree: Agree about that decoupling from templates
[2008-08-29 14::37:16] fabpot: let's take the template example
[2008-08-29 14::38:02] » You are now known as NiKo`.
[2008-08-29 14::38:04] fabpot: that way, we will be able to provide an HTML, Flex, ExtJs interface with the same architecture and share code
[2008-08-29 14::38:33] lvanderree: yes exactly
[2008-08-29 14::39:09] synace: fabpot: i think extJS should be supported out of the box
[2008-08-29 14::39:23] fabpot: synace: why? why not support Flex out of the box?
[2008-08-29 14::39:50] synace: fabpot: license issue point made
[2008-08-29 14::39:53] bschussek: yep. that's why I disagree with ExtJS by default
[2008-08-29 14::39:58] lvanderree: me 2
[2008-08-29 14::40:23] synace: as to extjs vs flex, extjs UI would be available to everyone w/o additional build (no need to build a flex app)
[2008-08-29 14::40:23] fabpot: as far as actions are concerned, I think that the default generated one will work for 99% of the case.
[2008-08-29 14::41:39] lvanderree: yep, as far as I have seen, only minimal changes are needed, but the standard possiblities can be extended
[2008-08-29 14::41:53] fabpot: so, in the template, we have 3 "objects/things": list widget, filter form, edit/create form
[2008-08-29 14::42:07] lvanderree: agree
[2008-08-29 14::42:42] bschussek: with list widget, do you mean a form widget?
[2008-08-29 14::43:04] fabpot: not a sfFormWidget, but a sfWidget
[2008-08-29 14::43:10] bschussek: okay
[2008-08-29 14::43:11] synace: fabpot: what about YUI / bsd license out of the box?
[2008-08-29 14::43:39] fabpot: synace: we need to provide 1 admin generator template system out of the box, so it must be the simplest one, and this is HTML
[2008-08-29 14::44:08] bschussek: I agree. IMO the most beautiful web interfaces still have been made with the combination HTML/Javascript
[2008-08-29 14::44:10] jvdlaan: yeah that is flexible enough.. Everyone can extend their wishes with plugins
[2008-08-29 14::44:14] synace: we're decoupling prototype right?
[2008-08-29 14::44:21] fabpot: synace: right
[2008-08-29 14::44:29] brankgnol_: I agree, all javascript stuff should be in plugins, so you can change of js framework
[2008-08-29 14::44:56] synace: agreed, plugins. but we should be building the first js plugin. that's sort of what I mean by "out of the box".. aka.. officially supported plugin
[2008-08-29 14::45:04] fabpot: no JavaScript library for the default template is allowed, except for pure JavaScript
[2008-08-29 14::45:25] synace: +1 brankgnol_ & fabpot
[2008-08-29 14::45:28] fabpot: ok, some plugins can be "officially" supported. We just need people to take care of that
[2008-08-29 14::45:40] lvanderree: I am here for a reason ;)
[2008-08-29 14::45:54] fabpot: thanks leon :D
[2008-08-29 14::46:21] lvanderree: how about the capabilities of the generator? we have already seen that we need form, filter and list views/templates
[2008-08-29 14::46:39] fabpot: Another thing, do we have to implement all the current features in the new system?
[2008-08-29 14::46:54] synace: fabpot: yes, and more.
[2008-08-29 14::46:57] fabpot: a filter is a form
[2008-08-29 14::47:02] lvanderree: I know :)
[2008-08-29 14::47:07] fabpot: we need to agree on the more
[2008-08-29 14::47:38] lvanderree: but what features do you mean
[2008-08-29 14::47:39] synace: fabpot: do you have a proposed feature list?
[2008-08-29 14::47:51] fabpot: no, we are here to discuss this list
[2008-08-29 14::48:34] lvanderree: agreee
[2008-08-29 14::48:35] jvdlaan: agree on that..
[2008-08-29 14::48:44] NiKo`: synace: I'm writing down what's said here in this wiki page : http://trac.symfony-project.org/wiki/SprintSymfony12AdminGenerator
[2008-08-29 14::48:56] lvanderree: but what do I need to think on, for features?
[2008-08-29 14::49:14] synace: yep NiKo`, just wanted to see if we had a base/starting point of discussion.which we do: the current symfony admin features
[2008-08-29 14::49:23] » pookey joined the chat room.
[2008-08-29 14::49:24] » jesepe joined the chat room.
[2008-08-29 14::49:27] pookey: moos
[2008-08-29 14::49:35] synace: widgets: list, filter, edit
[2008-08-29 14::49:49] fabpot: pookey: Niko` is writing a summary in real time: http://trac.symfony-project.org/wiki/SprintSymfony12AdminGenerator
[2008-08-29 14::50:13] bschussek: I think that, generally, very capable widgets in the edit/create form should be possible
[2008-08-29 14::50:15] fabpot: synace: right
[2008-08-29 14::50:19] pookey: fabpot: great :)
[2008-08-29 14::50:35] bschussek: I already explained some of that in the concept page http://trac.symfony-project.org/wiki/Symfony12AdminGenerator
[2008-08-29 14::50:51] synace: i would like to toss in at least 2 more: assign (which is a specialization of list), and define (which is a specialization of edit)
[2008-08-29 14::51:05] pookey: bschussek: I'd seen that page, I didn't know if it was 'offical' enough to present at SC
[2008-08-29 14::51:27] klemens_u: what's "SC"?
[2008-08-29 14::51:32] bschussek: pookey: I wrote on top that that's all my personal opinion, so the answer should be no
[2008-08-29 14::51:44] pookey: bschussek: that's what I thoguht :)
[2008-08-29 14::51:45] fabpot: klemens_u: symfonyCamp
[2008-08-29 14::52:00] klemens_u: i see, tnx
[2008-08-29 14::52:12] bschussek: you often have to take some input from the user, validate it and store it in some way. That's basically what the sfForm/sfValidator combination does, but that's not enough
[2008-08-29 14::52:13] fabpot: synace: after thinking a bit more about the widgets, we only have 1 widget: list
[2008-08-29 14::52:33] klemens_u: fabpot: how would this list widget work?
[2008-08-29 14::52:45] fabpot: like a data grid widget
[2008-08-29 14::53:08] synace: the forms must be extendable in order to be included as a component w/ ajax backend
[2008-08-29 14::53:10] fabpot: you pass a list of objects or a Criteria, or something else and it manages the rendering of the list, with pagination, ...
[2008-08-29 14::53:35] lvanderree: isn't a form a widget? forms can exist out of fieldsets, and maybe also out of tabpages (I see you also use this for the plugin-management website)
[2008-08-29 14::53:37] klemens_u: fabpot, i see
[2008-08-29 14::53:46] fabpot: synace: no pbe, the action will take care of this
[2008-08-29 14::54:27] synace: fabpot: just re-iterating, lvanderree: i could see a form as a widget too, but then it requires either ajax or leaving the form when processing
[2008-08-29 14::57:18] lvanderree: In my opinion the great thing of the current admin generator, is that it results in php-code which can be fully adjusted and extended. the admin-generator is very flexible, and I think it is very important to keep that. I don't know if not seeing forms as a widget will make the flexibility impossible?
[2008-08-29 14::57:42] synace: lvanderree: just like in factories you replace sfUser w/ myUser, just replace the form class w/ your extended one
[2008-08-29 14::57:52] lvanderree: ok
[2008-08-29 14::58:03] fabpot: lvanderree: the generated templates will be much more simpler in 1.2, because to output the form, this is just echo $form
[2008-08-29 14::58:22] lvanderree: not enough experience with sf1.1 for now, sorry about that ;) worked too much with 1.0 and the ExtjsTheme
[2008-08-29 14::58:54] fabpot: lvanderree: how do you output the form with extjs?
[2008-08-29 14::59:16] lvanderree: I generate and output Javascript-objects
[2008-08-29 15::00:38] fabpot: lvanderree: k
[2008-08-29 15::01:25] synace: fabpot: the additional widget I proposed: 'assign' is the same as 'SelectRelationAdminWidget' in notes, however, more extended
[2008-08-29 15::01:28] lvanderree: so in short: based on the edit.display array in the generator.yml I generate javascript code which describes and extended ExtJSForm-Object
[2008-08-29 15::01:52] synace: here is the concept for Relation: http://trac.symfony-project.org/attachment/wiki/Symfony12AdminGenerator/contextual_records_1.png
[2008-08-29 15::02:04] » silvain joined the chat room.
[2008-08-29 15::02:16] synace: here's my current use of an iframe/thickbox based relation system: http://moore.dev.whoisstudio.com/symfony_relations.png
[2008-08-29 15::02:16] pookey: synace: that's a nice feature
[2008-08-29 15::02:48] synace: this one goes further by letting you hold context of what you're doing in one view. (pure js can be used to accomplish also)
[2008-08-29 15::03:25] fabpot: synace: IIUC, you want to be able to create a new object when you have a select box?
[2008-08-29 15::03:40] synace: a slightly modified version of this includes a 'create' button as well, which re-uses the existing generator.yml & form to do creation
[2008-08-29 15::03:47] lvanderree: yes this one to many would be very nice to have (I think it is also called master-detail)
[2008-08-29 15::03:47] synace: fabpot: also filter for assignment
[2008-08-29 15::04:06] fabpot: synace: ok, I understand, I think this is a really nice feature that we can add to the "nice to have"
[2008-08-29 15::04:16] synace: fabpot: this functionality was actually back-ported from many-to-many
[2008-08-29 15::05:26] fabpot: synace: the only difficulty of this feature is 2 admin gen modules must know each other for this to work. As of now, each admin gen module is independant
[2008-08-29 15::05:44] lvanderree: yep correctly
[2008-08-29 15::05:49] synace: fabpot: yes, the configuration needs to be passed the other module
[2008-08-29 15::06:08] lvanderree: that is also a thing I had in mind, maybe we can add a "Singleton" AdminManager which allows you to get instances of different adminObjects
[2008-08-29 15::06:40] synace: fabpot: more to lvanderree's point, this would require passing only the object now, not the module
[2008-08-29 15::06:43] fabpot: lvanderree: not a singleton but an AdminManager is perhaps a good idea
[2008-08-29 15::07:08] pookey: sounds like we could really do with some kinda IoC system
[2008-08-29 15::07:09] lvanderree: singleton was just to give an idea of how it could work ;)
[2008-08-29 15::07:24] fabpot: pookey: IoC is planned for 2.0
[2008-08-29 15::07:28] pookey: ahh, good to know :)
[2008-08-29 15::07:45] fabpot: pookey: I will talk about the IoC implementation during symfonyCamp
[2008-08-29 15::07:47] lvanderree: i see
[2008-08-29 15::08:02] synace: in this view: http://moore.dev.whoisstudio.com/symfony_relations_m2m_edit.png you can see that the join table has a field (description) that can be edited from the assignment view
[2008-08-29 15::08:03] klemens_u: looking forward to it!
[2008-08-29 15::08:38] fabpot: so, this means that the sfAdminManager / sfAdmin must also manage the routing
[2008-08-29 15::08:43] pookey: lvanderree: I intend to do a quick demo of your admin enhancements btw
[2008-08-29 15::08:59] lvanderree: well still cool :D
[2008-08-29 15::09:06] synace: fabpot: that's fine by me, because it's customizable of course if needed
[2008-08-29 15::09:19] lvanderree: pookey: if you need tips, contact me
[2008-08-29 15::09:23] pookey: nods
[2008-08-29 15::10:39] mrcheese: Hello everybody
[2008-08-29 15::10:40] lvanderree: I have one-to-many relationships in my demo right now as well, but it isn't implemented in my generator, that is one of the custom parts, although really simple in my case, I simply define I need a javascript-object which is generated by another module
[2008-08-29 15::11:34] mrcheese: Just a quick question as I don't have time :-( to continue following this discussion: Am I the only one who would like to see such an sfAdmin list widget in the general forms as well...?
[2008-08-29 15::12:40] fabpot: mrcheese: the list widget will be independant of the admin gen
[2008-08-29 15::12:49] NiKo`: sfDataGrid :D
[2008-08-29 15::12:57] fabpot: sfWidgetDataGrid
[2008-08-29 15::13:07] NiKo`: sfWidgetEditableDataGrid :D
[2008-08-29 15::13:12] synace: ;)
[2008-08-29 15::13:17] mrcheese: I understand. But it is going to be a data grid which can also carry checkboxes or radio buttons
[2008-08-29 15::13:18] fabpot: sfWidgetPropelEditableDataGrid
[2008-08-29 15::13:47] mrcheese: I posted about this a couple of days ago in respect to sfForm but got no response... Symfony-dev list that was
[2008-08-29 15::14:33] » mysyfy joined the chat room.
[2008-08-29 15::15:01] mrcheese: after reading all that is said before i feel confident about the sfAdminGenerator
[2008-08-29 15::15:04] synace: NiKo`: can you attach those images to symfony-project.org please? thanks!
[2008-08-29 15::15:18] lvanderree: Thing I missed the most when I started creating real applications was the ability to use foreign-fields
[2008-08-29 15::15:29] NiKo`: synace: already done
[2008-08-29 15::15:49] synace: NiKo`: i mean i'll be taking down the domain after this discussion
[2008-08-29 15::15:51] NiKo`: synace: oops sorry, I won't leech any more
[2008-08-29 15::15:54] bschussek: lvanderree: IMO this would fit best into the ORMs
[2008-08-29 15::15:56] synace: no problem
[2008-08-29 15::16:01] lvanderree: for example when you have an overview on cities, and want to show the country each city is located in, you should be adding custom-methods (or partials)
[2008-08-29 15::16:04] mrcheese: but... To me there still seem to be some inconsistencies in the API of sfForm and since the admin generator relies heavily on that...
[2008-08-29 15::16:18] lvanderree: ORMs are already capable of doing this
[2008-08-29 15::16:20] bschussek: for example, you define a "representative column", which is used for __toString() and for sorting
[2008-08-29 15::16:38] fabpot: mrcheese: please, tell us more
[2008-08-29 15::16:39] lvanderree: at the moment the generator isn't aware of the foreign-fields
[2008-08-29 15::16:42] synace: NiKo`: also include: http://moore.dev.whoisstudio.com/symfony_relations_m2m_edit.png which showns a field for editing as well
[2008-08-29 15::16:43] jvdlaan: yeah we encountered that problem as well Leon.. (in 1.0 version that is)
[2008-08-29 15::16:49] bschussek: I already proposed this for Doctrine, and AFAIK it will be done in v2
[2008-08-29 15::17:15] mrcheese: well I think that the way sfForm handles checkboxes and radio buttons is counter intuitive
[2008-08-29 15::17:54] synace: NiKo`: http://moore.dev.whoisstudio.com/symfony_relations_m2m_edit_field.png the edit pencil clicked on a row
[2008-08-29 15::17:57] lvanderree: bschussek: lets first complete the discussion with mrcheesse
[2008-08-29 15::18:08] bschussek: yep, sorry for interrupting
[2008-08-29 15::18:13] fabpot: mrcheese: please, open a ticket, explain the problem, propose a new API, provide a patch with tests, and I will be very happy ;)
[2008-08-29 15::18:14] mrcheese: for multiple checkboxes you need to embed a form with multiple checkbox fields
[2008-08-29 15::18:15] lvanderree: me2
[2008-08-29 15::18:38] mrcheese: while for radio buttons it is a single widget
[2008-08-29 15::18:44] fabpot: mrcheese: no, you can create a new widget
[2008-08-29 15::19:08] mrcheese: well, i posted about this on the dev list but got no response. I asked there if i was to file a ticket
[2008-08-29 15::19:14] fabpot: mrcheese: but I understand your concern. Can you create that titcket, so we will have a reference to work on?
[2008-08-29 15::19:17] mrcheese: I am creating a widget for it now.
[2008-08-29 15::19:23] fabpot: mrcheese: thanks
[2008-08-29 15::19:40] mrcheese: unfortunately that will be tomorow as my meeting just walked in
[2008-08-29 15::19:44] pookey: symfony could definatly do with a powerful, very customisable table widget
[2008-08-29 15::19:48] fabpot: mrcheese: no problem
[2008-08-29 15::19:56] mrcheese: sorry. good luck and thanks for the great framework
[2008-08-29 15::20:01] » mrcheese left the chat room.
[2008-08-29 15::20:19] fabpot: pookey: do you want to work on this widget?
[2008-08-29 15::21:20] lvanderree: shall we continue about foreign fields?
[2008-08-29 15::21:25] fabpot: lvanderree: yes
[2008-08-29 15::21:36] » francoisz joined the chat room.
[2008-08-29 15::21:41] synace: fabpot: these screenshots are from a working demo
[2008-08-29 15::22:01] lvanderree: hi fraincois
[2008-08-29 15::22:08] pookey: fabpot: unfortunatly, I'm deep in the java world at the moment and I'm not finding time to do much else :|
[2008-08-29 15::22:09] francoisz: lvanderree: hi
[2008-08-29 15::22:10] bschussek: fabpot: I think the problem is, for instance, that you can include foreign records in a list view, but cannot filter or sort by default
[2008-08-29 15::22:26] fabpot: pookey: that's the problem with Java... too much XML ;)
[2008-08-29 15::22:27] pookey: however, that does mean that I'm slightly famialir with java's opinions of data tables
[2008-08-29 15::22:55] lvanderree: yep that is one of the problems
[2008-08-29 15::22:57] fabpot: pookey: I think it would be great if you can help us with some insights from the Java world
[2008-08-29 15::23:05] » jcoby joined the chat room.
[2008-08-29 15::23:13] synace: foreign-keys: standard popup window w/ a list of assignments that posts back a value to the opener on close
[2008-08-29 15::23:15] lvanderree: sorting on foreign-fields can be done automatically when the generator is aware of foreign-fields
[2008-08-29 15::23:17] fabpot: bschussek: ok, I get it now
[2008-08-29 15::23:19] synace: the popup window uses list & filter
[2008-08-29 15::24:00] bschussek: the problem get's more complicated when you not only want to display only one field, but a combination (like the famous "firstname lastname" example)
[2008-08-29 15::24:01] synace: (it's essentially a modification to list & filter for the foreign table, with an added object_action)
[2008-08-29 15::24:05] pookey: fabpot: I've spent the last 2 months reading, and my reading list has simply grown.. problem with java isn't too much XML, it's too much EVERYTHINg ;)
[2008-08-29 15::24:18] fabpot: lvanderree: so, you want to be able to display, filter, and sort for foreign objects, based on some columns
[2008-08-29 15::24:31] synace: bschussek: the model should then have to provide a method for sorting on this new 'field' you've created
[2008-08-29 15::24:34] fabpot: pookey: lol
[2008-08-29 15::24:55] pookey: a lack of datagrid has been a complaint I've heard before - but I think they are hard to get right
[2008-08-29 15::25:06] bschussek: synace: I agree. Actually this functionality belongs into the model
[2008-08-29 15::25:23] fabpot: pookey: yes, because you need lot of feature for a data grid to be useable
[2008-08-29 15::25:42] pookey: absolutly, it starts off seeming easy....
[2008-08-29 15::26:00] lvanderree: besides that, when the generator is aware of the foreign keys, you don't have to write custom-methodes (/partials) anymore for every custom field (which can really improve the overview and maintainability)
[2008-08-29 15::26:59] fabpot: lvanderree: yes, I was talking about single columns
[2008-08-29 15::27:00] synace: lvanderree: what about stacked view, maybe we need to append the filter widget to also provide the sorting
[2008-08-29 15::28:21] lvanderree: but for single columns I think it would be great if we can define a syntax (and implementation) which can return foreign fields
[2008-08-29 15::28:47] fabpot: lvanderree: I understand, NiKo` has added this feature on the list
[2008-08-29 15::29:10] synace: lvanderree: that's actually outside the point of filtering 'combined' fields.. that's foreign fields.. which, is doable in doctrine right now
[2008-08-29 15::29:15] lvanderree: 1. the amount of custom-method(/partials) you need, 2. sorting, 3. is usable to automatically allow code-completion (drop-down comboboxes) to select foreign items
[2008-08-29 15::29:57] fabpot: lvanderree: ok for 1 and 2, 3 is a total different beast
[2008-08-29 15::30:18] lvanderree: true, but this makes it possible
[2008-08-29 15::31:31] synace: fabpot: so, in the feature list for list, filter, we have: foreign keys supported, yes?
[2008-08-29 15::32:15] lvanderree: at the moment (symfony 1.0) generators. you can define drop-down comboboxes by providing the foreign-key, and it uses the toString method to show the text in the combos
[2008-08-29 15::32:21] fabpot: synace: yes, that's the plan
[2008-08-29 15::32:24] synace: how about custom fields (implementing the ability for admin to hunt for the properly named db model function to perform the lookup w/ the proper orderby clause)
[2008-08-29 15::33:13] lvanderree: I use the syntax: foreign-key/foreign-fieldname and use the primary key of the foreign-table as a value (just like 1.0) and the foreign-fieldname as a text (which again makes sorting possible)
[2008-08-29 15::33:37] fabpot: synace: custom fields already works in lists, for filters, you have to provide the implementation, and for sorting, it's not possible in 1.0
[2008-08-29 15::34:27] synace: fabpot: is there any way to provide filter & sort support for custom fields w/ the new architecture?
[2008-08-29 15::34:56] bschussek: lvanderree: considering drop downs with foreign key fields, there should be the possibility to sort them alphabetically
[2008-08-29 15::35:03] fabpot: synace: that's a nice to have feature
[2008-08-29 15::35:09] bschussek: be it in the filters, or in the edit view
[2008-08-29 15::35:20] synace: bschussek: you can currently provide a peerMethod on foreignKey fields, to which you can add sorting if you wish
[2008-08-29 15::35:27] lvanderree: bschussek: yes that is what I (meant to) say
[2008-08-29 15::35:40] synace: bschussek: but i'd much rather see a user-controlled datagrid on one-to-many assignment
[2008-08-29 15::35:52] lvanderree: bschussek: I do that at the moment already in the sfExtjsTheme ;)
[2008-08-29 15::36:34] francoisz: did anyone talk about the ability for plugins to simply enhance the generator capabilities?
[2008-08-29 15::36:40] synace: fabpot: how about implementing filter directly in list, leaving us w/ 1 widget: list and 1 form: edit
[2008-08-29 15::36:45] bschussek: synace: I know that it's possible currently, but with the foreign key field support this could be provided by the admin generator
[2008-08-29 15::37:07] fabpot: synace: I'm not sure this is a good idea. For big tables, it's a nightmare
[2008-08-29 15::37:36] francoisz: fabpot: thanks
[2008-08-29 15::37:53] synace: fabpot: i think that the filter is an extension of the list though, presentation aside
[2008-08-29 15::38:13] lvanderree: synace: about sorting on custom fields, there are two possibilites: this custom field is a column in your mysql-result set (which would allows mysql to do the sorting on this column), 2. you provide a extra parameter in your generator-configuration which defines which field to sort on for the custom-column and make mysql sort on this column, instead of the custom-column (which does not exist in mysql)
[2008-08-29 15::38:38] fabpot: synace: that's an interesting point of view for sure. But then perhaps we must have 2 widgets: a list widget and a filter list widget
[2008-08-29 15::39:03] synace: fabpot: that seems right, filterListWidget extends filterWidget
[2008-08-29 15::39:51] francoisz: I'm not shur what 'more decoupled' means; does it mean tha, if I want to add one feature to the generator, I shouldn't have to copy the whole theme?
[2008-08-29 15::39:53] synace: lvanderree: sorting needs to be done by the ORM/RDBMS, not by symfony, so the function would probably have to be hand written (in the manner that the custom field was written in the first place)
[2008-08-29 15::40:13] lvanderree: synace: I agree partly on that, that filters are part on the form. The problem with filtering in the head is you are restricted to filter on the columns in your grid
[2008-08-29 15::40:22] fabpot: francoisz: more decoupled means we will have more classes to extend from
[2008-08-29 15::40:42] bschussek: lvanderree: I think the presentation does not really depend on this architectural coupling
[2008-08-29 15::40:43] synace: francoisz: less spaghetti :)
[2008-08-29 15::41:06] lvanderree: synace: agree on filtering needed to be done by ORM/RDBMS but I think the defintion of this should be done in the generator, not in custom code.
[2008-08-29 15::41:33] francoisz: so I suggest to add this requirement to the list: ability to extend a theme easily for reusability
[2008-08-29 15::41:47] synace: lvanderree: it either has to be provided by the ORM, or by the developer making the custom field
[2008-08-29 15::42:08] francoisz: another concrete need that I don't see mentioned: put slots in the view code and events in the non-view code
[2008-08-29 15::42:47] fabpot: francoisz: what do you mean?
[2008-08-29 15::43:11] francoisz: the 1.0 generator uses _list_header partials and so on
[2008-08-29 15::43:13] lvanderree: +1 for reusability, I mentioned that before
[2008-08-29 15::43:56] francoisz: I think it would be smarter to put empty (or maybe not) slots in the view part of the generator, so that customizing a theme vwould just mean adding a template which fills the slots
[2008-08-29 15::44:16] fabpot: francoisz: ok, I understand
[2008-08-29 15::44:20] NiKo`: lvanderree: hey, I'm trying to do my best, just refresh the page now ;)
[2008-08-29 15::44:20] synace: francoisz: placeholders?
[2008-08-29 15::44:31] francoisz: synace: yes. slots are that
[2008-08-29 15::44:39] lvanderree: NiKo`: I don't have enough time ;)
[2008-08-29 15::44:41] francoisz: and events play the same role in controller/model classes
[2008-08-29 15::44:53] synace: francoisz: that's good, makes it easier to use existing code & not customize for simple additions
[2008-08-29 15::45:03] francoisz: synace: exactly
[2008-08-29 15::45:31] fabpot: francoisz: but where will you override the slot content for the listSuccess.php template for example?
[2008-08-29 15::45:32] synace: francoisz: but, that's also messy.. i could see 30 slots available to be dropped in any given page
[2008-08-29 15::46:04] francoisz: fabpot: good question
[2008-08-29 15::46:10] lvanderree: francoisz: KRavEN has made a nice implementation for this as well (like slots)
[2008-08-29 15::46:12] fabpot: synace: I don't think we will have that much slots: I think we need 3-5 per templates
[2008-08-29 15::46:37] lvanderree: KRavEN made it possible to define partials in the generator.yml for the sfExtjsThemePlugin
[2008-08-29 15::46:38] synace: fabpot: overriding the content would be done in the customization (child class), it couldn't be done anywhere else, no?
[2008-08-29 15::46:43] francoisz: fabpot: from what I understand, you want the view part of the generator to have less components, right?
[2008-08-29 15::47:01] fabpot: francoisz: right, the templates will be quite empty
[2008-08-29 15::47:55] francoisz: maybe empty partials are better than slots
[2008-08-29 15::48:30] synace: francoisz: that makes more sense to the content customization & roles in an organization (devs touch classes, front-end devs touch templates)
[2008-08-29 15::48:39] fabpot: francoisz: what we need is multiple-inheritance for templates, like in Django
[2008-08-29 15::48:43] bschussek: the problem that I currently see with the empty partials is that you cannot share them across modules
[2008-08-29 15::48:46] lvanderree: so instead of having 100 empty partials by default, we can define partials_filenames in the generator.yml and the generator would import these partials. However the problem with HTML is that you are depended on the location of the include.... In the sfExtjsTheme We use partials to add/overrule methods to our objects, so every partial contains a method which makes it really usable
[2008-08-29 15::48:51] francoisz: fabpot: definitely :)
[2008-08-29 15::49:12] synace: bschussek: makes a good point, however, you could easily just drop an include partial in each of those files and define a single one
[2008-08-29 15::49:56] bschussek: synace: the problem is, that these partials are, although very similar, often also dependent on the model/module. this could work with partial parameters though
[2008-08-29 15::49:57] francoisz: note: I don't see any mention, in the "must have", of the new forms system?
[2008-08-29 15::50:35] fabpot: francoisz: lol
[2008-08-29 15::50:45] francoisz: also, "decoupled" should mean somehow using an adapter approach to make the generator transposable to Doctrine
[2008-08-29 15::52:34] fabpot: francoisz: yes, sfAdminManager
[2008-08-29 15::52:44] lvanderree: :D
[2008-08-29 15::53:08] francoisz: ok
[2008-08-29 15::53:25] lvanderree: although I wonder how much can be done before the 1.2 release in september?
[2008-08-29 15::54:11] francoisz: ah, a tough one:
[2008-08-29 15::54:12] synace: fabpot: the list widget needs a further specialization now as well, listWidget, listFilerWidget extends listWidget, abstract listRelationWidget extends listFilterWidget, listRelationOneToManyWidget extends listFilterRelationWidget, and listRelationManyToManyWidget extends listRelationWidget
[2008-08-29 15::54:25] francoisz: at the moment, the generator allows to build up classes and modules
[2008-08-29 15::55:00] synace: francoisz: nav should be automatic based on modules, if enabled, but customizable via yml or db configuration
[2008-08-29 15::55:10] francoisz: synace: great
[2008-08-29 15::55:54] fabpot: nav should be automatic based on admin classes, not modules
[2008-08-29 15::55:58] lvanderree: probably also decoupled from representation somehow... since navigation is one of your keys for presentation
[2008-08-29 15::56:06] synace: i think the key here for the admin generator is 80/20.. make sure that it's functional, featured, and good for the people who just run generate & do nothing more (80% of 'developers')
[2008-08-29 15::56:33] fabpot: francoisz: the trick here is that sfAdminManager knows sfAdmin objects and knows the associated routing
[2008-08-29 15::56:53] lvanderree: sounds good
[2008-08-29 15::57:02] synace: fabpot: adminmanager is akin to an enable plugin module then? (injects routes, etc..)
[2008-08-29 15::57:30] francoisz: fabpot: so sfAdminManager can import assets? I don't get it
[2008-08-29 15::58:15] synace: NiKo`: add to nicetohaves filterint n:m
[2008-08-29 15::58:15] fabpot: francoisz: I'm not talking about assets here, just the possibility to link from an admin module to another and to provide a list of all available admin classes a la Django
[2008-08-29 15::58:30] francoisz: fabpot: ah ok. I understood
[2008-08-29 15::58:38] fabpot: francoisz: what is the pbe with assets?
[2008-08-29 15::58:45] francoisz: I'm fine with doing that from admin classes
[2008-08-29 15::59:35] fabpot: francoisz: ok, but I don't see how we can overcome this limitation
[2008-08-29 15::59:54] francoisz: me neither, that's why I said it's a tough one :)
[2008-08-29 16::00:02] fabpot: francoisz: if you bundle your assets in a plugin, np, if not, then you can just put your assets in your web/ directory, no?
[2008-08-29 16::01:00] francoisz: I don't know. What if you put your assets in a theme, not under the web dir of your project or your plugin, and somehow during generation the assets are made available to the web root folder
[2008-08-29 16::01:30] fabpot: A theme is just a bunch of templates, right?
[2008-08-29 16::01:31] synace: fabpot: update the mod_rewrite rules and serve the assets through sf :lol:
[2008-08-29 16::01:40] francoisz: synace: lol
[2008-08-29 16::02:07] fabpot: ok, another question: what is a theme?
[2008-08-29 16::02:25] synace: francoisz: plugins put symlinks in web, why couldn't themes?
[2008-08-29 16::02:27] fabpot: for me, it's some templates that override the default ones
[2008-08-29 16::02:31] francoisz: ok, probably not the most important evolution anyway. I'll try to find which use cases I had that made it a problem
[2008-08-29 16::02:40] fabpot: francoisz: ok
[2008-08-29 16::02:45] bschussek: fabpot: but also the images, css and js files associated with the templates, right?
[2008-08-29 16::02:48] lvanderree: representation + actions
[2008-08-29 16::03:01] synace: fabpot: i have 2 terms used to describe customization in my circa 2002 php4 framework
[2008-08-29 16::03:57] fabpot: lvanderree: the question is: is ExtJs or Flex support just a theme?
[2008-08-29 16::04:01] » roberto__ joined the chat room.
[2008-08-29 16::04:17] fabpot: lvanderree: if yes, then I'm with you, a theme is composed of templates and actions
[2008-08-29 16::04:18] lvanderree: fabpot: yep I see, that
[2008-08-29 16::04:27] synace: a-la php-nuke.. a 'theme' might be color changes only (css, color settings), where as a new 'style' (there's probably a better term, nuke called it templates), is completely new templates
[2008-08-29 16::05:00] fabpot: for me, ExtJs or Flex support are done by 2 plugins, so they are not a theme per se
[2008-08-29 16::05:37] synace: extjs support needs custom controller code as well though, so that puts it outside the concept of just 'theme'
[2008-08-29 16::05:39] lvanderree: that was why I said representation + actions, since at the moment themes contain both, although I agree this might be a llitle awkward
[2008-08-29 16::05:55] fabpot: Perhaps, Flex will provide more features than ExtJs, so we really talk about extensions/plugins, not just a theme
[2008-08-29 16::06:17] lvanderree: fabpot: agree, not just a theme
[2008-08-29 16::06:49] francoisz: while we are speaking about style, I think the new generator should be sexy
[2008-08-29 16::06:58] bschussek: francoisz: absolutely agree
[2008-08-29 16::06:58] lvanderree: in my opinion a theme should be about representation only. So color, and arrangement of elements
[2008-08-29 16::07:08] francoisz: I mean, that's already a "Wow" factor for symfony
[2008-08-29 16::07:25] bschussek: although sexiness for me means also real usability
[2008-08-29 16::07:28] synace: francoisz: if it's gonna be sexy, it's gotto have fk's ;)
[2008-08-29 16::07:35] francoisz: bschussek: I'm with you on that
[2008-08-29 16::07:46] fabpot: francoisz: I'm with you on this one. The current one is just too ugly.
[2008-08-29 16::07:57] francoisz: synace: right. We may not share the same definition for sexy :)
[2008-08-29 16::08:01] synace: fabpot: i don't mind the look at all.. it's an admin panel
[2008-08-29 16::08:19] fabpot: synace: customer, IT managers, and new symfony developers care
[2008-08-29 16::08:38] lvanderree: for ExtJs, and probably other Javascript implementations as well, you don't send the representation and the data at the same time, so where you would send one page which contains both, me layout/representation in javascript request for the JSON-data only (which is constructed from the same generator in the theme)
[2008-08-29 16::08:41] bschussek: we currently use the admin generator for a backend with a large audience of mainly inexperienced computer users. Usability is really important here
[2008-08-29 16::08:41] synace: every customer i have given it to loves it
[2008-08-29 16::09:24] francoisz: who designed the generator theme concept screenshots attached to http://trac.symfony-project.org/wiki/Symfony12AdminGenerator ? they kick ass, I think
[2008-08-29 16::09:27] synace: i agree w/ bschussek: sexy = usability
[2008-08-29 16::09:33] fabpot: can we rename theme by skin? to be more exact on what we mean?
[2008-08-29 16::09:48] bschussek: francoisz: that was me. I based it on joyent, a real sexy application (= usable)
[2008-08-29 16::09:57] synace: fabpot: i like skin
[2008-08-29 16::10:22] bschussek: http://www.joyent.com/connector/collaboration-suite/screenshots/
[2008-08-29 16::10:26] francoisz: so maybe a nice to have feature would be: handle multiple skins natively - at least 2
[2008-08-29 16::11:01] lvanderree: but if we have skins, what are themes going to have?
[2008-08-29 16::11:07] fabpot: francoisz: propriatary
[2008-08-29 16::11:12] francoisz: damn
[2008-08-29 16::11:13] bschussek: francoisz: I really don't know. I made the sketches up from scratch, if that's what you want to know
[2008-08-29 16::11:31] francoisz: so we need a good designer to come up with a sexy skin
[2008-08-29 16::11:48] fabpot: lvanderree: theme won't exist anymore. I just want to change the name to make it clear what it can do
[2008-08-29 16::11:52] francoisz: that's probably a nice to have feature, though
[2008-08-29 16::11:52] bschussek: we could ask the joyent designer
[2008-08-29 16::12:02] fabpot: bschussek: lol
[2008-08-29 16::12:03] synace: francoisz: we should have wireframes of our widget views so as to not leave the actual features to the designer ;)
[2008-08-29 16::12:09] bschussek: :-)
[2008-08-29 16::12:48] francoisz: did anyone mention the ability to have a show view?
[2008-08-29 16::13:08] synace: i don't see a need
[2008-08-29 16::13:10] lvanderree: fabpot: agree on removing the theme name, think skins is more appropriate, but where does the admin-generator exists of then? it now exists out of a theme (actions and templates) and a admin-generator-library
[2008-08-29 16::13:16] francoisz: or to have no list view? I have designed a generator theme that had only an edit view
[2008-08-29 16::13:32] synace: though, it should be something possible. let's add it to must
[2008-08-29 16::13:37] fabpot: francoisz: 2 skins natively: a very simple one which is semantic and easy to skin with only stylesheets, and another one which is more appealing
[2008-08-29 16::13:46] synace: +1
[2008-08-29 16::13:50] lvanderree: francoisz: nope, show view not seen +1 on that
[2008-08-29 16::13:51] francoisz: +1
[2008-08-29 16::13:56] synace: fabpot: allows us to build w/o waiting for a designer
[2008-08-29 16::14:28] francoisz: also, that may be too much, but can the admin manager handle security?
[2008-08-29 16::14:30] fabpot: actions + templates = module in symfony
[2008-08-29 16::15:14] lvanderree: true
[2008-08-29 16::15:36] synace: francoisz: generator based? we should add a lot of automatically defined permissions so that they can be granular and assigned w/ the likes of sfGuard
[2008-08-29 16::15:41] » klemens_ joined the chat room.
[2008-08-29 16::16:04] francoisz: synace: or bundle sfGuard with symfony and use it in the generator :)
[2008-08-29 16::16:24] synace: i don't see why sfGuard isn't bundled.. but then again, we're talking about decoupling here
[2008-08-29 16::16:31] fabpot: Off Topic: What about bundling sfGuard with symfony 1.2?
[2008-08-29 16::16:31] francoisz: right
[2008-08-29 16::16:46] bschussek: +1
[2008-08-29 16::16:47] synace: +1
[2008-08-29 16::16:57] lvanderree: security related, it might be nice if this can be more fine grained as well, for example to define if some thing is editable/read-only/not-visible at all
[2008-08-29 16::17:00] synace: (it's easily removable and replaceable if that's the goal.. )
[2008-08-29 16::17:07] francoisz: (off topic: sfGuard+sfDoctrineGuard?)
[2008-08-29 16::17:07] bschussek: It's really just a DB implementation of the built-in credentials
[2008-08-29 16::17:09] synace: +1 if an interface is well defined in sfUser
[2008-08-29 16::17:23] klemens_: lvanderee: +1 especially the "readable"
[2008-08-29 16::17:35] synace: lvanderree: +1
[2008-08-29 16::18:11] francoisz: one other request: I'd like the actions list to made 'ajaxable', meaning that I can click on a button on a row (say, delete) and continue doing things on the same page
[2008-08-29 16::18:20] klemens_: apropos readable / slightly offtopic: I had the requirement a few times, that for example some fields in a sfForm should be set to readonly
[2008-08-29 16::18:25] synace: francoisz: +1000
[2008-08-29 16::18:25] francoisz: probably a nice to have feature
[2008-08-29 16::18:55] klemens_: that is also a requirement for the edit action of the admin generator
[2008-08-29 16::18:57] synace: francoisz: i would also like to see list view actions able to be opened in layers (or windows, depending on js)
[2008-08-29 16::19:04] bschussek: francoisz: +1, such AJAX features are really necessary for a good usability (= sexiness again :-) )
[2008-08-29 16::19:19] » klemens_u left the chat room.
[2008-08-29 16::19:21] synace: that gives way to all the features i'm asking for in 1:n n:n
[2008-08-29 16::19:27] bschussek: that includes editing related records in form fields again, without having to leave the form
[2008-08-29 16::19:29] fabpot: francoisz: in the requirements, we said that we don't want to use a JavaScript library and limit he use of JavaScript
[2008-08-29 16::19:37] silvain: question: in 1.0 we had validate.yml .. in 1.1 the validation is defined in PHP with the form ... but if the admin generator generates the form in 1.2, then how do i specify the validation for the admin generator?
[2008-08-29 16::19:38] » jamiel joined the chat room.
[2008-08-29 16::19:48] francoisz: ok, then we can use pure js then :)
[2008-08-29 16::19:53] fabpot: francoisz: lol
[2008-08-29 16::20:14] synace: fabpot: that limits us greatly.... why not just bundle jquery w/ noConflict ;)
[2008-08-29 16::20:15] fabpot: NiKo`: françois will take care of all the Ajax stuff in 1.2 without any JS framework
[2008-08-29 16::20:16] bschussek: actually we could release a javascript plugin that unobstrusively adds these features
[2008-08-29 16::20:27] fabpot: bschussek: +1
[2008-08-29 16::20:32] synace: francoisz: volunteered :)
[2008-08-29 16::20:39] francoisz: whatwhatwhat?
[2008-08-29 16::20:41] synace: bschussek: +++
[2008-08-29 16::20:52] klemens_: bschussek: yes punobstrusively, definitly
[2008-08-29 16::20:53] synace: exactly!
[2008-08-29 16::21:00] lvanderree: I think all this ajaxines is possible in an extended skin.... but does a skin contain this much knowledge, again the problem of seperation between representation and code
[2008-08-29 16::21:18] bschussek: this could, again, rely on a javascript library and can be ported to different libraries
[2008-08-29 16::21:29] francoisz: so that would be a plugin extending the basic generator theme? Ok, if the generator theme is extensible enough
[2008-08-29 16::21:31] synace: bschussek: yes, but that's problematic
[2008-08-29 16::21:48] bschussek: synace: you mean because of admin generator extensions?
[2008-08-29 16::21:52] synace: yes
[2008-08-29 16::21:55] bschussek: I agree
[2008-08-29 16::22:17] francoisz: so, does that mean that the generator won't support the ability to add related records without leaving the main page?
[2008-08-29 16::22:24] fabpot: bschussek: you're right, but we won't need to "port" to different librairies as François is working on an abstraction of all existing JS librayr into one consistent API
[2008-08-29 16::22:27] synace: francoisz: popup?
[2008-08-29 16::22:42] francoisz: ah
[2008-08-29 16::22:43] bschussek: synace: i personally hate popups
[2008-08-29 16::22:48] synace: it can easily do stuff w/ native js and popup and simple html rewrites
[2008-08-29 16::22:48] francoisz: bschussek: me too
[2008-08-29 16::23:02] synace: bschussek: can we do DHTML layers?
[2008-08-29 16::23:05] francoisz: damn, its 2008, guys
[2008-08-29 16::23:06] bschussek: a javascript simple roll out can do as well
[2008-08-29 16::23:27] francoisz: fabpot: don't make fun of me
[2008-08-29 16::23:32] lvanderree: isn't this what extjs is doing ;)
[2008-08-29 16::23:33] synace: bschussek: i'm actually using iframes for my relational tool ;) w/ js polling and auto-resize
[2008-08-29 16::23:35] fabpot: francoisz: sorry :|
[2008-08-29 16::23:36] synace: lvanderree: yes
[2008-08-29 16::23:42] francoisz: fabpot: or I'll make fun of you when you end up using my stuff
[2008-08-29 16::24:19] synace: i think there needs to be a clear choice for novice developers to be able to use a js enabled editor w/ these features out of the box
[2008-08-29 16::24:32] francoisz: synace: right
[2008-08-29 16::24:49] bschussek: francoisz: well done on the DbFinder, by the way ;-) (sorry for going off topic)
[2008-08-29 16::25:03] francoisz: bschussek: WAY off topic, but thanks
[2008-08-29 16::25:03] lvanderree: he deserves the credtis
[2008-08-29 16::25:33] synace: since we're off-topic: when we redoing sf in php5.3 ;)
[2008-08-29 16::25:38] fabpot: the question is: will we be able to unobstrusively add Ajax stuff on the default templates?
[2008-08-29 16::25:43] francoisz: if the problem of the js lib is just about how to write an Ajax link/form, this can easily be abstracted into a helper and decided during generation
[2008-08-29 16::25:55] synace: fabpot: it depends on our implementation of the controllers..
[2008-08-29 16::26:18] francoisz: doesn't sound simple, but as long as we give the choice of the js lib, we have to support all
[2008-08-29 16::26:24] jamiel: Whos going to make us some new buttons ...
[2008-08-29 16::26:29] lvanderree: synace: agree, depends on controller
[2008-08-29 16::26:29] bschussek: francoisz: actually, a thing like DbFinder, but for javascript libraries, should be possible, shouldn't it?
[2008-08-29 16::26:42] francoisz: bschussek: what, you want to write it?
[2008-08-29 16::26:54] lvanderree: hehe
[2008-08-29 16::26:58] bschussek: erm ... no :-) I really am not that experienced with javascript
[2008-08-29 16::27:05] francoisz: I think using jQuery with compat mode is the best choice
[2008-08-29 16::27:34] synace: mit also
[2008-08-29 16::27:34] fabpot: francoisz: I agree with the jQuery choice but what about people wanting to use YUI or prototype?
[2008-08-29 16::27:46] lvanderree: ExtJs has adapters to support different javascript frameworks, but I never touched them
[2008-08-29 16::27:46] francoisz: another skin
[2008-08-29 16::27:55] synace: jquery/yui/ext all get along
[2008-08-29 16::28:02] francoisz: synace: how?
[2008-08-29 16::28:06] NiKo`: I think we should not bundle a given js lib with symfony
[2008-08-29 16::28:16] lvanderree: I too think that if you want to do this, you should choose one JS-framework, not mixing all of them
[2008-08-29 16::28:18] synace: NiKo`: agreed
[2008-08-29 16::28:39] klemens_: Sadly I've to leave now. I'm looking forward to read everything later in the wiki (big thank you to Nicolas)
[2008-08-29 16::28:42] francoisz: so basically, that brings us back to the former statement: no js in the default theme?
[2008-08-29 16::28:48] NiKo`: furthermore, I think a lot of unobstrusive ajaxification can be done in a separated js file
[2008-08-29 16::28:58] lvanderree: and have a skin for every framework
[2008-08-29 16::29:19] synace: lvanderree: sure, sf builds one w/ jquery to start
[2008-08-29 16::29:21] fabpot: back to square one: don't you think it will be quite easy to add JS behavior on the default templates?
[2008-08-29 16::29:24] synace: and then, it can be replaced w/ another one
[2008-08-29 16::29:31] » klemens_ left the chat room.
[2008-08-29 16::29:40] bschussek: fabpot: you mean without any libraries?
[2008-08-29 16::29:44] fabpot: we can bundled the needed actions for Ajax
[2008-08-29 16::29:45] francoisz: So how about that: in the generator.yml (or whatever it will be), there is a param to activate Ajax stuff, that can take different values according to the js lib you use?
[2008-08-29 16::29:45] synace: fabpot: i think it can be done w/ native js, but if we can separate it to a plugin, that would be best
[2008-08-29 16::30:18] fabpot: francoisz: this means that we need to provide an implementatino for every single library out there?
[2008-08-29 16::30:27] NiKo`: the real thing is to have/provide all needed ajax actions, but thanks to the sf_format it's quite easy to do provide default needed actions easily in a lot of output format
[2008-08-29 16::30:34] francoisz: fabpot: just the ones we want to support
[2008-08-29 16::30:39] lvanderree: fabpot: agree on that, bundle the actions, keep the implementation of the javascript for plugins which contain new skins
[2008-08-29 16::30:52] francoisz: fabpot: and maybe just one, and we live the others to whoever wants to write them
[2008-08-29 16::30:53] synace: francoisz/fabpot, it's the same issue (and should be same resolution) as doctrine/propel
[2008-08-29 16::31:14] francoisz: I agree with synace
[2008-08-29 16::31:25] fabpot: synace: more or less. we only have 2 ORMs in PHP. There are 10 great JavaScript libraries
[2008-08-29 16::31:25] francoisz: don't give users too much choice at the beginning
[2008-08-29 16::31:30] NiKo`: to me, all of these js-libraries-coupled stuff should be done in externals plugins
[2008-08-29 16::31:33] francoisz: choice is the ennemy of usability
[2008-08-29 16::31:33] synace: francoisz: exactly
[2008-08-29 16::31:40] NiKo`: core should just provide default ajax-enabled actions
[2008-08-29 16::31:41] bschussek: I agree
[2008-08-29 16::31:47] synace: francoisz: the linux syndrome.. way too much choice (the mythtv syndrome!!)
[2008-08-29 16::31:48] fabpot: jQuery, mootools, Dojo, YUI, prototype, ...
[2008-08-29 16::31:57] synace: NiKo`: +
[2008-08-29 16::32:26] francoisz: NiKo`: and end up writing Yet Another Js Lib?
[2008-08-29 16::32:28] synace: fabpot: yahoo doesn't even use doctrine/propel
[2008-08-29 16::32:33] bschussek: then again: if we support no JS, we have to write everything ourselves and we end up writing a new library
[2008-08-29 16::32:35] francoisz: NiKo`: not sure it's the best idea
[2008-08-29 16::32:36] synace: which suffice to say, they don't use the admin generator
[2008-08-29 16::32:44] NiKo`: francoisz: core should not contain one line of js to me
[2008-08-29 16::32:51] synace: bschussek: true
[2008-08-29 16::33:01] NiKo`: except if(confirm('Sure?'))
[2008-08-29 16::33:08] francoisz: NiKo`: ah, just actions, right
[2008-08-29 16::33:19] synace: i think it's clear then... no js, provide one (or two) hand-picked js libraries from the go as a plugin
[2008-08-29 16::33:19] lvanderree: there can be one js-framework provide by default, rest can be done by plugins from the community
[2008-08-29 16::33:23] synace: and make that the 'default' choice
[2008-08-29 16::33:28] NiKo`: yep. You want Propel2JSON output ? sf_format is there for that
[2008-08-29 16::33:44] bschussek: lvanderree: It should be bundled as plugin though
[2008-08-29 16::33:45] synace: lvanderree: negative, the js needs to be a plugin from the start
[2008-08-29 16::34:06] francoisz: NiKo`: actions without templates, that don't work out of the box?
[2008-08-29 16::34:07] synace: francoisz: will agree that it needs to be bundled by default though
[2008-08-29 16::34:07] bschussek: but you could provide the hooks for the plugins by default
[2008-08-29 16::34:23] lvanderree: bschussek/synace: sorry meant that, one plugin with one framework, but natively supported...
[2008-08-29 16::34:30] bschussek: +1
[2008-08-29 16::34:31] synace: bschussek: some.. probably not all.. the plugin should provide a custom class extension of the base classes
[2008-08-29 16::34:47] jcoby: have helpers been discussed yet?
[2008-08-29 16::34:51] synace: ex: yourAdminClass extends sfAdmin... becomes: yourAdminClass extends sfJqueryAdmin
[2008-08-29 16::35:19] francoisz: back to some features: how about credentials on columns display?
[2008-08-29 16::35:29] bschussek: synace: I don't know whether I want to inherit a new admin class just because of the JS framework...
[2008-08-29 16::35:34] synace: the js plugins have to provide specialization and theme, not just theme
[2008-08-29 16::35:58] fabpot: francoisz: already added with 3 states: read-only, not-displayed, editable
[2008-08-29 16::36:11] francoisz: fabpot: great
[2008-08-29 16::36:57] synace: fabpot: want to summarize admin & js implementation?
[2008-08-29 16::37:04] francoisz: a small feature: can the wildcard be automatic in text filters?
[2008-08-29 16::37:12] synace: francoisz: +1
[2008-08-29 16::37:25] bschussek: I think it already is, isn't it?
[2008-08-29 16::37:33] francoisz: bschussek: nope
[2008-08-29 16::37:42] fabpot: francoisz: ok, Google style
[2008-08-29 16::37:43] synace: not inline
[2008-08-29 16::38:15] jcoby: francoisz: being able to type in part of an email to find a user would be nice
[2008-08-29 16::38:16] synace: francoisz: example: 'callout' search: cal%t
[2008-08-29 16::38:17] bschussek: fabpot: +1 most users are used to Google
[2008-08-29 16::38:18] synace: works
[2008-08-29 16::38:20] francoisz: not inline, but if I serach for 'fab' I should find 'fabpot' and 'potfab'
[2008-08-29 16::38:26] synace: francoisz: it does for me
[2008-08-29 16::38:42] francoisz: synace: I had to override the default them to add that!
[2008-08-29 16::38:54] synace: francoisz: i don't think i did.. :/
[2008-08-29 16::38:57] francoisz: synace: you probably did somethog in the actions class
[2008-08-29 16::39:15] jcoby: synace: definitely doesn't work for me in 1.0. i tried it yesterday (the above email example)
[2008-08-29 16::39:27] synace: francoisz: negatory.. this is a low-budget admin build ;)
[2008-08-29 16::39:39] francoisz: synace: there you have it
[2008-08-29 16::39:40] synace: jcoby: francoisz: doctrine or propel?
[2008-08-29 16::39:47] jcoby: synace: propel
[2008-08-29 16::39:49] francoisz: synace: those Doctrine guys are so way ahead ;)
[2008-08-29 16::40:04] bschussek: we should provide a tree data grid by default for displaying nested sets
[2008-08-29 16::40:06] synace: yeah, wage is doing a great job.. i was trying to hire him before fabien did ;)
[2008-08-29 16::40:11] francoisz: bschussek: !
[2008-08-29 16::40:33] synace: i remember when I used to play video games w/ him back in the day and he would bug me about simple php stuff ;)
[2008-08-29 16::40:36] francoisz: bschussek: nice to have feature, but greatly depends on how you implement the nested sets
[2008-08-29 16::40:47] synace: bschussek: plugin
[2008-08-29 16::40:58] bschussek: francoisz: unfortunately yes
[2008-08-29 16::41:08] NiKo`: bschussek: this could be a widget
[2008-08-29 16::41:09] synace: francoisz: users expect this type of stuff out of the box
[2008-08-29 16::41:21] NiKo`: bschussek: but I cannot see it as a core widget
[2008-08-29 16::41:34] francoisz: also, how about a way to override the query made to populate select filters, without the need to implement a partial filter?
[2008-08-29 16::41:38] synace: NiKo`: plugin widget
[2008-08-29 16::42:04] francoisz: I mean, from the generator.yml
[2008-08-29 16::42:12] synace: yeah, add peerMethod support to filters
[2008-08-29 16::42:33] francoisz: (or womething else: see how DbFinder generator allows 'model filters' to be added to any query)
[2008-08-29 16::43:00] bschussek: one question, that is probably rather related to sfForm: how would it be possible to generalize such a widget for the admin generator? http://trac.symfony-project.org/attachment/wiki/Symfony12AdminGenerator/widgets.png
[2008-08-29 16::43:04] fabpot: francoisz: added to the list
[2008-08-29 16::43:15] francoisz: also, the ability to define the list of options for a filter amnually in the generator.yml
[2008-08-29 16::43:27] synace: that's really a field type
[2008-08-29 16::43:49] bschussek: that means, a map widget that uses two fields and could also do some custom polling dependent on a third field "address"
[2008-08-29 16::43:59] synace: bschussek: i think it's one field
[2008-08-29 16::44:02] fabpot: francoisz: after some thought, a filter is just a form, so you will be able to do all those stuff natively
[2008-08-29 16::44:06] synace: abstracted to display as 2 in the partial
[2008-08-29 16::44:15] bschussek: synace: I agree, but how would one implement it?
[2008-08-29 16::44:28] francoisz: fabpot: if the generator.yml gives a simple way to do that, fine :)
[2008-08-29 16::44:28] bschussek: reusable, with sfForm
[2008-08-29 16::44:28] fabpot: bschussek: you mean, a GMaps widget
[2008-08-29 16::44:29] jcoby: synace: every implementation of lat/lon pairs i've ever seen has been two columns
[2008-08-29 16::44:38] bschussek: fabpot: yes
[2008-08-29 16::44:46] synace: jcoby: then we need support for multiple fields w/ 1 label
[2008-08-29 16::44:55] fabpot: bschussek: looks like easy to do
[2008-08-29 16::45:05] synace: jcoby: which is possible w/ partials.. which will be possible w/ the new admin classes
[2008-08-29 16::45:08] francoisz: also a nice to have feature, if we have an sfAdminManager to hadle side menus: a breadcrumb
[2008-08-29 16::45:22] bschussek: can you elaborate? my biggest problem is how to bundle all the logic to be easily usable in a different admin module
[2008-08-29 16::45:24] francoisz: And the ability to nest admin modules
[2008-08-29 16::45:29] jcoby: i've done a little GIS work where I stored geocoords as a POINT column, but that's not available in many rdbms.
[2008-08-29 16::45:36] fabpot: jcoby: not a problem, you have one widget but 2 validators
[2008-08-29 16::46:04] jcoby: fabpot: ahh, ok
[2008-08-29 16::46:08] bschussek: fabpot: and where do you put the logic for the custom address polling?
[2008-08-29 16::46:20] synace: bschussek: i think you'll need to do the same thing pretty much as now.. a 'partial' which is a widget.. and validation for the 2 separate fields, and a custom view which includes the 2 fields and the widget
[2008-08-29 16::46:52] francoisz: also: can the peerMethod used for the list depend on the credentials?
[2008-08-29 16::46:52] fabpot: bschussek: I don't understand the question
[2008-08-29 16::47:01] francoisz: or should that be implemented in the model (brr)
[2008-08-29 16::47:06] synace: francoisz: hrm
[2008-08-29 16::47:52] jcoby: custom address polling? it looks like a simple javascript exercise to grab the point's lat/lon and fill out the fields.
[2008-08-29 16::47:53] francoisz: I don't know where this should be implemented, but there is definitely a need for some records to be hidden based on credentials
[2008-08-29 16::48:07] synace: i suppose it could be done in the configuration
[2008-08-29 16::48:26] bschussek: fabpot: I actually can have three fields: "address", "longitude" and "latitude". If the address is given but no longitude and latitude, I poll the data from a google server. users can use the JS map to refine the coordinates
[2008-08-29 16::49:01] fabpot: bschussek: all this features must be included in the widget
[2008-08-29 16::49:11] jcoby: bschussek: then you're going to be getting into localization problems.
[2008-08-29 16::49:23] bschussek: fabpot: exactly
[2008-08-29 16::49:24] francoisz: another nice to have feature: next/prev buttons in the edit/show view
[2008-08-29 16::49:41] synace: francoisz: by sorting in list view used to get to this edit page
[2008-08-29 16::49:53] francoisz: synace: naturally
[2008-08-29 16::50:01] jcoby: francoisz: agreed.
[2008-08-29 16::50:04] bschussek: fabpot: but the widget doesn't include the validators, does it`
[2008-08-29 16::50:15] synace: i wouldn't say it does bschussek
[2008-08-29 16::50:17] fabpot: bschussek: no
[2008-08-29 16::50:21] bschussek: and that's the problem
[2008-08-29 16::50:29] fabpot: bschussek: why?
[2008-08-29 16::50:38] synace: bschussek: admin mixins?
[2008-08-29 16::50:48] fabpot: bschussek: as it's a bit offtopic, we can talk about that later
[2008-08-29 16::51:07] bschussek: fabpot: I agree. I just thougth this might affect the features of the generator
[2008-08-29 16::51:08] jcoby: feature i'd like to see: automatic hiding of lazy load columns in the view action.
[2008-08-29 16::51:40] synace: jcoby: if no field list specified?
[2008-08-29 16::51:46] jcoby: synace: yes
[2008-08-29 16::52:09] synace: jcoby: i would say no lazyload by default in list
[2008-08-29 16::52:17] jcoby: synace: right, sorry, i meant list
[2008-08-29 16::52:19] brankgnol_: hope NiKo didn't missed francoisz last resquest.. :)
[2008-08-29 16::52:28] synace: gotcah
[2008-08-29 16::52:33] francoisz: brankgnol_: no, he didn't. I check the wiki page :)
[2008-08-29 16::52:40] NiKo`: brankgnol_: nope, it's been added on the page
[2008-08-29 16::53:03] francoisz: NiKo`: yes
[2008-08-29 16::53:05] brankgnol_: :)
[2008-08-29 16::53:07] synace: what did everyone think of adding this on: listWidget, listFilerWidget extends listWidget, abstract listRelationWidget extends listFilterWidget, listRelationOneToManyWidget extends listFilterRelationWidget, and listRelationManyToManyWidget extends listRelationWidget
[2008-08-29 16::53:13] » jvdlaan left the chat room.
[2008-08-29 16::53:27] synace: if they need JS, they would require the jsAdmin plugin
[2008-08-29 16::54:03] jcoby: what do you think about adding admin attributes to the model like django?
[2008-08-29 16::54:31] francoisz: NiKo`: could you write that the sfAdminManager must be able to generate a navigation menu (and maybe a breadcrumb) ?
[2008-08-29 16::54:34] bschussek: jcoby: isn't this a quuestion of the ORM?
[2008-08-29 16::55:19] jcoby: bschussek: kind of. django actually controls the admin interface through a metaclass on the model. what fields are shown, how they're shown, etc. basically the whole generator.yml
[2008-08-29 16::55:26] synace: what was our conclusion on JS-ified admin?
[2008-08-29 16::55:47] francoisz: synace: the wiki page says: no js
[2008-08-29 16::55:48] » shawncplus joined the chat room.
[2008-08-29 16::55:53] lvanderree: :S I was away for maybe 5 minutes, took my 10 minutes to read this all :D
[2008-08-29 16::56:01] bschussek: jcoby: yeah. I wished we had only one validation layer in symfony based on the model, that could be extended in the forms. then we would have that possibility
[2008-08-29 16::56:09] synace: francoisz: i though we were doing a plugin bundled & enabled by default, but replaceable ?
[2008-08-29 16::56:51] lvanderree: I saw something mentioned about filtering again, which reminded me of another feature I had in mind: chaining of combos For example if you want your user to choose a city, let him narrow down the options by first selecting a country
[2008-08-29 16::57:02] francoisz: synace: unobtrusive Ajax/effects, depending on a library, added afterwards?
[2008-08-29 16::57:11] synace: francoisz: yes, but bundled
[2008-08-29 16::57:32] francoisz: synace: so that means symfony must bundle a js lib, and I don't think it's the case
[2008-08-29 16::57:41] synace: francoisz: no, the plugin will bundle the js lib
[2008-08-29 16::57:49] francoisz: synace: bad idea
[2008-08-29 16::57:50] synace: or require the appropriate js plugin that does
[2008-08-29 16::57:58] francoisz: synace: better idea :)
[2008-08-29 16::58:08] synace: i come up w/ them all day ;)
[2008-08-29 16::58:28] francoisz: but if you bundle the admin js plugin by default, then it doesn't make sense not to bundle the js lib by default as well
[2008-08-29 16::58:46] synace: decoupled, easily replaced
[2008-08-29 16::59:16] francoisz: fabpot: what's your opinion on that?
[2008-08-29 16::59:39] synace: we were also talking about bundling sfGuard
[2008-08-29 16::59:56] fabpot: synace: Propel and Doctrine will be bundled with sf 1.2. And then in 1.3, Propel will be removed from core and available as a plugin.
[2008-08-29 17::00:13] lvanderree: isn't it possible to bundle the sfFinder plugin, to make it ORM independed?
[2008-08-29 17::00:17] fabpot: francoisz: I really think we don't want to bundle a JS library
[2008-08-29 17::00:18] synace: i say +1 for sfGuard, sfAdmin, sfDoctrine, and sfJqueryPlugin and sfJqueryAdmin out of the gate in sf1.3
[2008-08-29 17::00:36] jcoby: bschussek: yeah.. that's how django works :)
[2008-08-29 17::00:41] NiKo`: to me, +1 bundling sfGuard, -1 for bundling any js lib/framework
[2008-08-29 17::00:42] francoisz: fabpot: then we forget the sexy skin
[2008-08-29 17::00:59] synace: francoisz: exactly.. we also forget tons of usability
[2008-08-29 17::01:07] fabpot: francoisz: is the Django admin sexy?
[2008-08-29 17::01:14] brankgnol_: NiKo +1
[2008-08-29 17::01:20] francoisz: fabpot: more than symfony's :)
[2008-08-29 17::01:21] synace: fabpot: no... it's limited in functionality
[2008-08-29 17::01:25] fabpot: francoisz: and no JS
[2008-08-29 17::01:27] bschussek: jcoby: there's one other advantage: right now it's possible to insert wrong data on the controller layer, if the validation is only defined in the forms. This wouldn't be possible otherwise
[2008-08-29 17::01:50] NiKo`: francoisz: ajax doesn't mean useable, oftem it's quite the opposite
[2008-08-29 17::01:57] synace: fabpot: what's the ultimate priority of sexy: visual look, or functionality & usability?
[2008-08-29 17::01:58] francoisz: so let's write that down in marble so that we don't ask the same question again and again
[2008-08-29 17::02:05] jcoby: bschussek: right. which is why RoR and django both do model-level validation.
[2008-08-29 17::02:10] francoisz: NiKo`: sure we can come up with something usable
[2008-08-29 17::02:29] bschussek: jcoby: awesome. but let's keep that for later maybe and stay on one topic :-)
[2008-08-29 17::02:35] synace: bschussek: that's a different topic altogether, but a very very good one
[2008-08-29 17::02:45] francoisz: NiKo`: but in the cases we talked about (list actions, related records edition/deletion/addition), Ajax can easily add usability
[2008-08-29 17::02:53] synace: francoisz: exactly
[2008-08-29 17::02:58] lvanderree: about model validation +1 for that, just like credential checking at model level, instead of module
[2008-08-29 17::02:59] synace: which is why i would like it bundled
[2008-08-29 17::03:07] jcoby: if you bundle sfGuard, can you make it possible to have the sfGuardUserProfile actually editable from the admin?
[2008-08-29 17::03:29] bschussek: francoisz: I agree. I suggest that you sign up for a free Joyent account, IMO they are a very good example for well-used AJAX to improve usability
[2008-08-29 17::03:37] synace: jcoby: i have a customized module of sfGuardAdmin->profile that does all that it's pretty easy
[2008-08-29 17::04:08] francoisz: clearly there are two camps there, and clearly this is something that can be added as a plugin
[2008-08-29 17::04:11] jcoby: synace: perhaps. i spent an hour trying to find a way to do it and just gave up. seems odd that it doesn't have native support for it.
[2008-08-29 17::04:45] francoisz: so let's build the plugin at the same time as the generator, to make sure the actions are there and that the unobtrusive scripting has the DOM ids to hook up to
[2008-08-29 17::04:46] synace: francoisz: the only debate then is whether to bundle as standard available functionality (we already know it's going to be a decoupled plugin)
[2008-08-29 17::04:58] bschussek: francoisz: https://customer.joyent.com/signup/customer
[2008-08-29 17::05:06] francoisz: synace: NiKo` and fabpot say no, I won't argue
[2008-08-29 17::05:57] fabpot: ok, it's 17:00. I will have to left in about 15 minutes...
[2008-08-29 17::06:17] synace: fabpot: +/- on bundling a javascript plugin and js-enabled admin by default (but decoupled & replaceable, a-la doctrine/propel)
[2008-08-29 17::06:18] bschussek: what about tabs in edit views? (js again, I know)
[2008-08-29 17::06:47] lvanderree: I like the idea of validation and credential checking on model level, instead of module level
[2008-08-29 17::06:58] jcoby: bschussek: seems like a minor extension to the current groupings?
[2008-08-29 17::06:58] bschussek: and one last big topic: proper support of I18N!
[2008-08-29 17::07:00] » mysyfy_ joined the chat room.
[2008-08-29 17::07:01] » mysyfy left the chat room.
[2008-08-29 17::07:08] fabpot: bschussek: what for? to replace the existing sections?
[2008-08-29 17::07:25] bschussek: easier navigation on long edit pages
[2008-08-29 17::07:35] francoisz: synace: let's make it this way: it is a plugin for now, not bundled with symfony 1.2, but it is so good and so much used that fabpot can't just not bundle it with symfony 1.3
[2008-08-29 17::07:44] synace: bschussek: if you switch tabs and leave the context of changes in a hidden tab, then hit save to store values of a hidden tab, thats = bad usability
[2008-08-29 17::08:29] bschussek: synace: I disagree, if the save button is clearly placed outside of the tabbed area
[2008-08-29 17::08:30] synace: francoisz: that's the way I feel about it ;) every other system out there will have js, and users will feel like sf is missing something w/o it. we can't let implementation and preference be the reason to not include it
[2008-08-29 17::09:01] lvanderree: bschussek: I agree on that :) clearly visible save button fixes trhat
[2008-08-29 17::09:20] » rafix joined the chat room.
[2008-08-29 17::09:43] bschussek: silverstripe is a good example for that: http://demo.silverstripe.com/
[2008-08-29 17::09:44] jcoby: synace: that means that just about every preference dialog in windows and os x and gnome and kde are bad usability
[2008-08-29 17::09:50] francoisz: synace: if the generator is extensible enough, tons of skins/themes will be published, each with some Ajax to show off!
[2008-08-29 17::09:51] lvanderree: But I haven't seen a good argument not to bundle it by the way
[2008-08-29 17::10:01] synace: lvanderree: i don't disagree that you need a save btn. i just think that saving data should not be done w/ hidden context. if you do that, you need isolated context
[2008-08-29 17::10:52] bschussek: so what about I18N?
[2008-08-29 17::11:00] fabpot: bschussek: added to the list
[2008-08-29 17::11:03] francoisz: bschussek: handled by sfForms
[2008-08-29 17::11:08] bschussek: indeed?
[2008-08-29 17::11:14] fabpot: bschussek: yes
[2008-08-29 17::11:18] jcoby: synace: it would be the same in the admin. as long as the tab switching was instant and the save button was outside of the tabs.
[2008-08-29 17::11:52] synace: NiKo`: my experience w/ 1:n and n:n was that building n:n was hard, and 1:n was a simple modification of 1:n.. so they're both either 'nice to haves' or both 'very hard nice to haves' not different
[2008-08-29 17::11:53] bschussek: fabpot: is there some possibility to see the text of some other language while editing a record? (like translating)
[2008-08-29 17::11:54] francoisz: is easy handling of file columns a feature we wish?
[2008-08-29 17::12:05] jcoby: francoisz: yes
[2008-08-29 17::12:13] fabpot: francoisz: yes
[2008-08-29 17::12:40] jcoby: ideally with in-database and out-of-database storage
[2008-08-29 17::12:41] fabpot: francoisz: I will commit a new file widget for the admin with support for delete and a preview. You can already see it in action in the plugins/ section of sf.org
[2008-08-29 17::12:46] synace: francoisz: widget
[2008-08-29 17::12:49] fabpot: bschussek: yes
[2008-08-29 17::13:05] bschussek: fabpot: great, then I'm happy :-)
[2008-08-29 17::13:13] lvanderree: well let met try it for the third time, what are the opinions about validation and credential checking at model level? instead of at module level
[2008-08-29 17::13:27] synace: lvanderree: off topic, but +10,000
[2008-08-29 17::13:32] bschussek: lvanderree: I absolutely would like that, but it's ORM related
[2008-08-29 17::13:34] jcoby: lvanderree: let's move that to sf-devs
[2008-08-29 17::13:34] » k88 joined the chat room.
[2008-08-29 17::13:41] » saganxis joined the chat room.
[2008-08-29 17::13:47] francoisz: lvanderree: -1 for me
[2008-08-29 17::13:48] lvanderree: but it is related to the generator
[2008-08-29 17::13:49] fabpot: lvanderree: the problem is that we use externals libraries for the model, Propel or Doctrine
[2008-08-29 17::14:01] jcoby: lvanderree: i was going to start an email on it in a bit
[2008-08-29 17::14:19] fabpot: lvanderree: but let's discuss that on the dev ML if you want
[2008-08-29 17::14:23] synace: lvanderree: then we have to define the permissions and validation at the generator level, or provide a singleton interface for all forms to use on the model
[2008-08-29 17::14:33] lvanderree: fabpot: I see, maybe an extra generator to do this outside the module level?
[2008-08-29 17::14:56] fabpot: lvanderree: with the new forms, validation is done by the form, so it is outside of the module level
[2008-08-29 17::15:08] synace: francoisz: you gonna be working on the sfJSAdmin ?
[2008-08-29 17::15:32] » gnat42 joined the chat room.
[2008-08-29 17::15:33] lvanderree: fabpot: OK good, And I will start a thread/post in the ML
[2008-08-29 17::15:41] francoisz: synace: er... dunno
[2008-08-29 17::15:47] » silvain left the chat room.
[2008-08-29 17::16:22] bschussek: fabpot: since you have to leave, will you come back today? I remember the meeting being set until 18:00GMT
[2008-08-29 17::16:22] synace: NiKo`: thx for making js-potential-support must have
[2008-08-29 17::16:49] NiKo`: synace: if it's potential, it can't be a must have...
[2008-08-29 17::16:51] gnat42: was this conversation logged sompleace?
[2008-08-29 17::17:04] fabpot: bschussek: I know, but I forgot that I had to leave earlier today to pick up my children
[2008-08-29 17::17:05] lvanderree: maybe it is wise to sleep/think a weekend about all what has been said
[2008-08-29 17::17:07] NiKo`: gnat42: yes, log will be attached to the wiki page
[2008-08-29 17::17:14] synace: NiKo`: i meant thanks for putting it must-have, it = "make it so js can be written as a plugin"
[2008-08-29 17::17:32] gnat42: NiKo`: thanks
[2008-08-29 17::17:40] bschussek: fabpot: ok. where can we continue the discussion of the details and the distribution of work? ML?
[2008-08-29 17::17:41] lvanderree: define some real requirements from the points summarised in the wiki and meet again after that
[2008-08-29 17::17:56] fabpot: bschussek: right, let's talk about people wanting to help
[2008-08-29 17::18:21] francoisz: I think someone is calling me on the other line
[2008-08-29 17::18:25] bschussek: I do
[2008-08-29 17::18:37] synace: i might be able to provide some company time for the JS stuff.. what's the timeline for delivery?
[2008-08-29 17::18:38] fabpot: Ok, let's add the names on the wiki page
[2008-08-29 17::18:58] francoisz: I can help with the doc ;)
[2008-08-29 17::19:31] fabpot: synace: I want to release 1.2 alpha in October... I know, it will come very fast ;)
[2008-08-29 17::19:38] synace: francoisz: fabpot: do you want to see a quick demo of the relation tool? i can provide url/user/pass
[2008-08-29 17::19:56] lvanderree: I can help implementing foreign keys, but I don't know how to do this ORM-independed? I can make it work for Propel ;) have that already, but it can get optimised somewhat
[2008-08-29 17::20:04] francoisz: fabpot: how about the generator.yml syntax?
[2008-08-29 17::20:12] fabpot: I will work on the basic architecture, the base classes, ... to ease the contributions
[2008-08-29 17::20:20] bschussek: lvanderree: If you know how to do it in Propel, than Doctrine is only a small step, honestly :-)
[2008-08-29 17::20:45] fabpot: francoisz: the first step is to implement everything in PHP and then add the .yml file. And I'm sure you are the one to define the format
[2008-08-29 17::20:52] lvanderree: OK, maybe we can both take a look at it, after I have optimised the Propel version
[2008-08-29 17::21:16] fabpot: so, I will create an admin-gen branch from 1.2
[2008-08-29 17::21:25] lvanderree: I think we first need a base for the Php config
[2008-08-29 17::21:34] francoisz: ah ok
[2008-08-29 17::21:41] fabpot: and I will grant access to people willing to help
[2008-08-29 17::21:52] synace: NiKo`: 2 edits
[2008-08-29 17::22:10] fabpot: if you want to help, please send me an email with your trac login, so I can give you write access to the branch
[2008-08-29 17::22:24] synace: move "Be able to sort and filter on foreign objects based on some columns (n:m relationship) " to "nice to haves" or move "Be able to sort and filter on foreign objects based on some columns (1:n relationship only) " to "will be very hard.."
[2008-08-29 17::22:31] bschussek: fabpot: rgr. how are we going to coordinate the work?
[2008-08-29 17::22:32] fabpot: I will give you access just after the initial phase of implementation, which means when I will have created the base structure
[2008-08-29 17::23:01] NiKo`: BTW, what about backward compatibility between old admin gen and the upcoming one ?
[2008-08-29 17::23:02] bschussek: fabpot: ok
[2008-08-29 17::23:10] NiKo`: (hint: we're on a 1.x branch)
[2008-08-29 17::23:31] synace: fabpot: off-topic: sensio uses scrum i take it?
[2008-08-29 17::23:55] bschussek: NiKo`: we could generate the generator configuration based on the generator.yml (wow...)
[2008-08-29 17::23:59] francoisz: NiKo`: there is a class name on top of the generator.yml
[2008-08-29 17::24:07] fabpot: NiKo`: as sfCompat10 won't be in 1.2, I think it is just not possible to keep compatibility
[2008-08-29 17::24:25] francoisz: NiKo`: we need to ship the old classes and name the new generator differently
[2008-08-29 17::24:44] synace: fabpot: fork w/ both available in 1.2, remove old in 1.3?
[2008-08-29 17::24:44] francoisz: (not like validator classes in pre-1.0)
[2008-08-29 17::25:24] » roberto__ left the chat room.
[2008-08-29 17::25:26] » jcoby_ joined the chat room.
[2008-08-29 17::25:46] NiKo`: if we don't want to keep the sfCompat10 plugin, we must forget keeping the old admin gen as well
[2008-08-29 17::25:50] francoisz: I meant pre-1.1
[2008-08-29 17::25:57] synace: rgr
[2008-08-29 17::26:02] fabpot: synace: if we keep the old admin gen in 1.2, it means we need to keep sfCompat10 and upgrade it to Propel 1.3, that's a lot of work
[2008-08-29 17::26:06] » sf___ joined the chat room.
[2008-08-29 17::26:15] fabpot: francoisz: it was fixed before the release of 1.1 ;)
[2008-08-29 17::26:29] lvanderree: I say remove sfCompat10
[2008-08-29 17::26:33] synace: +1 remove
[2008-08-29 17::26:39] francoisz: ok, so that brings us to another off-topic question: should symfony 1.2 be renamed symfony 2.0 ?
[2008-08-29 17::26:45] » roberto__ joined the chat room.
[2008-08-29 17::26:49] fabpot: francoisz: lol
[2008-08-29 17::26:56] synace: francoisz: on this release cycle & w/ propel still bundled: no
[2008-08-29 17::26:56] NiKo`: francoisz: you're my troll-hero \o/
[2008-08-29 17::27:04] » sf___ is now known as sf.
[2008-08-29 17::27:10] francoisz: NiKo`: it takes years to learn
[2008-08-29 17::27:15] NiKo`: (but this makes sense indeed)
[2008-08-29 17::27:23] lvanderree: people can keep working in 1.0 and if they want to have nicer stuff, they need to upgrade their own code, which probably isn't that hard
[2008-08-29 17::27:31] fabpot: that makes sense
[2008-08-29 17::27:54] synace: what's preventing pulling propel now then?
[2008-08-29 17::28:18] lvanderree: at least 1.6 ;) rounds to 2.0
[2008-08-29 17::28:33] synace: new people to sf 2.0 should then have no question of what to use..
[2008-08-29 17::28:36] francoisz: but that also means that upgrading from 1.1 won't be possible
[2008-08-29 17::29:04] fabpot: francoisz: as far as the admin gen. is concerned, well, yes
[2008-08-29 17::29:06] synace: i didn't say: don't update propel, i just meant: don't ship probel
[2008-08-29 17::29:21] francoisz: so, in "nice to have", I think symfony 1.0 generator.yml compatibility should figure
[2008-08-29 17::29:44] NiKo`: francoisz: the major purpose of increment the major number of a release is to be able to break the public API
[2008-08-29 17::29:56] synace: francoisz: then you need sfCompat10 and everything else
[2008-08-29 17::29:57] » k88 left the chat room.
[2008-08-29 17::30:00] synace: +1 NiKo`
[2008-08-29 17::30:06] francoisz: NiKo`: I agree. But that would be quite deceptive for those who started in 1.1
[2008-08-29 17::30:27] fabpot: ok, I have to leave now. Thanks everybody for your contributions. Keep talking, I will read the logs tonight...
[2008-08-29 17::30:30] NiKo`: francoisz: I agree :/
[2008-08-29 17::30:40] bschussek: fabpot: see you! thanks for the nice meeting
[2008-08-29 17::30:43] fabpot: Perhaps we need to keep sfCompat10 in sf1.2
[2008-08-29 17::30:50] synace: francoisz: branch!
[2008-08-29 17::30:58] francoisz: synace: are you crazy?
[2008-08-29 17::31:03] synace: yes ;)
[2008-08-29 17::31:11] » fabpot left the chat room.