Development

SprintSymfony12AdminGenerator: symfony-sprint.log

You must first sign up to be able to contribute.

SprintSymfony12AdminGenerator: symfony-sprint.log

File symfony-sprint.log, 80.9 kB (added by nicolas, 9 years ago)

IRC log (plain text)

Line 
1 [2008-08-29 14::17:03] » You left the chat by being disconnected from the server.
2 [2008-08-29 14::20:22] » You rejoined the room.
3 [2008-08-29 14::20:50] lvanderree: you don't want to miss a word, it it
4 [2008-08-29 14::21:33] » chrisbur joined the chat room.
5 [2008-08-29 14::22:02] » silvain left the chat room.
6 [2008-08-29 14::22:15] » You left the chat by being disconnected from the server.
7 [2008-08-29 14::22:36] » You rejoined the room.
8 [2008-08-29 14::22:57] fabpot: NiKo` will takes notes during this session
9 [2008-08-29 14::23:28] lvanderree: ah nice
10 [2008-08-29 14::23:41] jvdlaan: k nice
11 [2008-08-29 14::27:53] » klemens_u left the chat room.
12 [2008-08-29 14::28:06] » klemens_u joined the chat room.
13 [2008-08-29 14::28:50] » bschussek joined the chat room.
14 [2008-08-29 14::28:56] lvanderree: there he is
15 [2008-08-29 14::29:07] bschussek: hi all
16 [2008-08-29 14::29:10] lvanderree: ola
17 [2008-08-29 14::30:10] fabpot: ok, François has left, but I'm still here
18 [2008-08-29 14::32:01] bschussek: I agree. A decoupled admin generator would also mean more flexibility in extending different parts of it
19 [2008-08-29 14::32:05] fabpot: We can have a .yml configuration file, but this is optional
20 [2008-08-29 14::32:30] klemens_u: good aproach.
21 [2008-08-29 14::32:40] fabpot: So, we need a main object for each object, something like ArticleAdmin, CommentAdmin, ...
22 [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
23 [2008-08-29 14::33:08] fabpot: This ArticleAdmin extends sfAdmin and all the configuration can be done in this class
24 [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
25 [2008-08-29 14::34:44] klemens_u: agree.
26 [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
27 [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
28 [2008-08-29 14::35:52] fabpot: anything else I'm missing here?
29 [2008-08-29 14::35:52] synace: does sfAdmin extends sfActions?
30 [2008-08-29 14::36:05] fabpot: no, sfAdmin is independant of the controller
31 [2008-08-29 14::36:08] lvanderree: this Object is configured in a config-constructor, like you do in the sfForm-way
32 [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)
33 [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
34 [2008-08-29 14::36:26] » NiKo` left the chat room.
35 [2008-08-29 14::36:36] fabpot: synace: exactly
36 [2008-08-29 14::36:57] synace: fabpot: good consistent w/ the rest of the 1.2 approach
37 [2008-08-29 14::37:09] lvanderree: Agree about that decoupling from templates
38 [2008-08-29 14::37:16] fabpot: let's take the template example
39 [2008-08-29 14::38:02] » You are now known as NiKo`.
40 [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
41 [2008-08-29 14::38:33] lvanderree: yes exactly
42 [2008-08-29 14::39:09] synace: fabpot: i think extJS should be supported out of the box
43 [2008-08-29 14::39:23] fabpot: synace: why? why not support Flex out of the box?
44 [2008-08-29 14::39:50] synace: fabpot: license issue point made
45 [2008-08-29 14::39:53] bschussek: yep. that's why I disagree with ExtJS by default
46 [2008-08-29 14::39:58] lvanderree: me 2
47 [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)
48 [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.
49 [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
50 [2008-08-29 14::41:53] fabpot: so, in the template, we have 3 "objects/things": list widget, filter form, edit/create form
51 [2008-08-29 14::42:07] lvanderree: agree
52 [2008-08-29 14::42:42] bschussek: with list widget, do you mean a form widget?
53 [2008-08-29 14::43:04] fabpot: not a sfFormWidget, but a sfWidget
54 [2008-08-29 14::43:10] bschussek: okay
55 [2008-08-29 14::43:11] synace: fabpot: what about YUI / bsd license out of the box?
56 [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
57 [2008-08-29 14::44:08] bschussek: I agree. IMO the most beautiful web interfaces still have been made with the combination HTML/Javascript
58 [2008-08-29 14::44:10] jvdlaan: yeah that is flexible enough.. Everyone can extend their wishes with plugins
59 [2008-08-29 14::44:14] synace: we're decoupling prototype right?
60 [2008-08-29 14::44:21] fabpot: synace: right
61 [2008-08-29 14::44:29] brankgnol_: I agree, all javascript stuff should be in plugins, so you can change of js framework
62 [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
63 [2008-08-29 14::45:04] fabpot: no JavaScript library for the default template is allowed, except for pure JavaScript
64 [2008-08-29 14::45:25] synace: +1 brankgnol_ & fabpot
65 [2008-08-29 14::45:28] fabpot: ok, some plugins can be "officially" supported. We just need people to take care of that
66 [2008-08-29 14::45:40] lvanderree: I am here for a reason ;)
67 [2008-08-29 14::45:54] fabpot: thanks leon :D
68 [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
69 [2008-08-29 14::46:39] fabpot: Another thing, do we have to implement all the current features in the new system?
70 [2008-08-29 14::46:54] synace: fabpot: yes, and more.
71 [2008-08-29 14::46:57] fabpot: a filter is a form
72 [2008-08-29 14::47:02] lvanderree: I know :)
73 [2008-08-29 14::47:07] fabpot: we need to agree on the more
74 [2008-08-29 14::47:38] lvanderree: but what features do you mean
75 [2008-08-29 14::47:39] synace: fabpot: do you have a proposed feature list?
76 [2008-08-29 14::47:51] fabpot: no, we are here to discuss this list
77 [2008-08-29 14::48:34] lvanderree: agreee
78 [2008-08-29 14::48:35] jvdlaan: agree on that..
79 [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
80 [2008-08-29 14::48:56] lvanderree: but what do I need to think on, for features?
81 [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
82 [2008-08-29 14::49:23] » pookey joined the chat room.
83 [2008-08-29 14::49:24] » jesepe joined the chat room.
84 [2008-08-29 14::49:27] pookey: moos
85 [2008-08-29 14::49:35] synace: widgets: list, filter, edit
86 [2008-08-29 14::49:49] fabpot: pookey: Niko` is writing a summary in real time: http://trac.symfony-project.org/wiki/SprintSymfony12AdminGenerator
87 [2008-08-29 14::50:13] bschussek: I think that, generally, very capable widgets in the edit/create form should be possible
88 [2008-08-29 14::50:15] fabpot: synace: right
89 [2008-08-29 14::50:19] pookey: fabpot: great :)
90 [2008-08-29 14::50:35] bschussek: I already explained some of that in the concept page http://trac.symfony-project.org/wiki/Symfony12AdminGenerator
91 [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)
92 [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
93 [2008-08-29 14::51:27] klemens_u: what's "SC"?
94 [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
95 [2008-08-29 14::51:44] pookey: bschussek: that's what I thoguht :)
96 [2008-08-29 14::51:45] fabpot: klemens_u: symfonyCamp
97 [2008-08-29 14::52:00] klemens_u: i see, tnx
98 [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
99 [2008-08-29 14::52:13] fabpot: synace: after thinking a bit more about the widgets, we only have 1 widget: list
100 [2008-08-29 14::52:33] klemens_u: fabpot: how would this list widget work?
101 [2008-08-29 14::52:45] fabpot: like a data grid widget
102 [2008-08-29 14::53:08] synace: the forms must be extendable in order to be included as a component w/ ajax backend
103 [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, ...
104 [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)
105 [2008-08-29 14::53:37] klemens_u: fabpot, i see
106 [2008-08-29 14::53:46] fabpot: synace: no pbe, the action will take care of this
107 [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
108 [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?
109 [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
110 [2008-08-29 14::57:52] lvanderree: ok
111 [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
112 [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
113 [2008-08-29 14::58:54] fabpot: lvanderree: how do you output the form with extjs?
114 [2008-08-29 14::59:16] lvanderree: I generate and output Javascript-objects
115 [2008-08-29 15::00:38] fabpot: lvanderree: k
116 [2008-08-29 15::01:25] synace: fabpot: the additional widget I proposed: 'assign' is the same as 'SelectRelationAdminWidget' in notes, however, more extended
117 [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
118 [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
119 [2008-08-29 15::02:04] » silvain joined the chat room.
120 [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
121 [2008-08-29 15::02:16] pookey: synace: that's a nice feature
122 [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)
123 [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?
124 [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
125 [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)
126 [2008-08-29 15::03:47] synace: fabpot: also filter for assignment
127 [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"
128 [2008-08-29 15::04:16] synace: fabpot: this functionality was actually back-ported from many-to-many
129 [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
130 [2008-08-29 15::05:44] lvanderree: yep correctly
131 [2008-08-29 15::05:49] synace: fabpot: yes, the configuration needs to be passed the other module
132 [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
133 [2008-08-29 15::06:40] synace: fabpot: more to lvanderree's point, this would require passing only the object now, not the module
134 [2008-08-29 15::06:43] fabpot: lvanderree: not a singleton but an AdminManager is perhaps a good idea
135 [2008-08-29 15::07:08] pookey: sounds like we could really do with some kinda IoC system
136 [2008-08-29 15::07:09] lvanderree: singleton was just to give an idea of how it could work ;)
137 [2008-08-29 15::07:24] fabpot: pookey: IoC is planned for 2.0
138 [2008-08-29 15::07:28] pookey: ahh, good to know :)
139 [2008-08-29 15::07:45] fabpot: pookey: I will talk about the IoC implementation during symfonyCamp
140 [2008-08-29 15::07:47] lvanderree: i see
141 [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
142 [2008-08-29 15::08:03] klemens_u: looking forward to it!
143 [2008-08-29 15::08:38] fabpot: so, this means that the sfAdminManager / sfAdmin must also manage the routing
144 [2008-08-29 15::08:43] pookey: lvanderree: I intend to do a quick demo of your admin enhancements btw
145 [2008-08-29 15::08:59] lvanderree: well still cool :D
146 [2008-08-29 15::09:06] synace: fabpot: that's fine by me, because it's customizable of course if needed
147 [2008-08-29 15::09:19] lvanderree: pookey: if you need tips, contact me
148 [2008-08-29 15::09:23] pookey: nods
149 [2008-08-29 15::10:39] mrcheese: Hello everybody
150 [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
151 [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...?
152 [2008-08-29 15::12:40] fabpot: mrcheese: the list widget will be independant of the admin gen
153 [2008-08-29 15::12:49] NiKo`: sfDataGrid :D
154 [2008-08-29 15::12:57] fabpot: sfWidgetDataGrid
155 [2008-08-29 15::13:07] NiKo`: sfWidgetEditableDataGrid :D
156 [2008-08-29 15::13:12] synace: ;)
157 [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
158 [2008-08-29 15::13:18] fabpot: sfWidgetPropelEditableDataGrid
159 [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
160 [2008-08-29 15::14:33] » mysyfy joined the chat room.
161 [2008-08-29 15::15:01] mrcheese: after reading all that is said before i feel confident about the sfAdminGenerator
162 [2008-08-29 15::15:04] synace: NiKo`: can you attach those images to symfony-project.org please? thanks!
163 [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
164 [2008-08-29 15::15:29] NiKo`: synace: already done
165 [2008-08-29 15::15:49] synace: NiKo`: i mean i'll be taking down the domain after this discussion
166 [2008-08-29 15::15:51] NiKo`: synace: oops sorry, I won't leech any more
167 [2008-08-29 15::15:54] bschussek: lvanderree: IMO this would fit best into the ORMs
168 [2008-08-29 15::15:56] synace: no problem
169 [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)
170 [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...
171 [2008-08-29 15::16:18] lvanderree: ORMs are already capable of doing this
172 [2008-08-29 15::16:20] bschussek: for example, you define a "representative column", which is used for __toString() and for sorting
173 [2008-08-29 15::16:38] fabpot: mrcheese: please, tell us more
174 [2008-08-29 15::16:39] lvanderree: at the moment the generator isn't aware of the foreign-fields
175 [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
176 [2008-08-29 15::16:43] jvdlaan: yeah we encountered that problem as well Leon.. (in 1.0 version that is)
177 [2008-08-29 15::16:49] bschussek: I already proposed this for Doctrine, and AFAIK it will be done in v2
178 [2008-08-29 15::17:15] mrcheese: well I think that the way sfForm handles checkboxes and radio buttons is counter intuitive
179 [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
180 [2008-08-29 15::17:57] lvanderree: bschussek: lets first complete the discussion with mrcheesse
181 [2008-08-29 15::18:08] bschussek: yep, sorry for interrupting
182 [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 ;)
183 [2008-08-29 15::18:14] mrcheese: for multiple checkboxes you need to embed a form with multiple checkbox fields
184 [2008-08-29 15::18:15] lvanderree: me2
185 [2008-08-29 15::18:38] mrcheese: while for radio buttons it is a single widget
186 [2008-08-29 15::18:44] fabpot: mrcheese: no, you can create a new widget
187 [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
188 [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?
189 [2008-08-29 15::19:17] mrcheese: I am creating a widget for it now.
190 [2008-08-29 15::19:23] fabpot: mrcheese: thanks
191 [2008-08-29 15::19:40] mrcheese: unfortunately that will be tomorow as my meeting just walked in
192 [2008-08-29 15::19:44] pookey: symfony could definatly do with a powerful, very customisable table widget
193 [2008-08-29 15::19:48] fabpot: mrcheese: no problem
194 [2008-08-29 15::19:56] mrcheese: sorry. good luck and thanks for the great framework
195 [2008-08-29 15::20:01] » mrcheese left the chat room.
196 [2008-08-29 15::20:19] fabpot: pookey: do you want to work on this widget?
197 [2008-08-29 15::21:20] lvanderree: shall we continue about foreign fields?
198 [2008-08-29 15::21:25] fabpot: lvanderree: yes
199 [2008-08-29 15::21:36] » francoisz joined the chat room.
200 [2008-08-29 15::21:41] synace: fabpot: these screenshots are from a working demo
201 [2008-08-29 15::22:01] lvanderree: hi fraincois
202 [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 :|
203 [2008-08-29 15::22:09] francoisz: lvanderree: hi
204 [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
205 [2008-08-29 15::22:26] fabpot: pookey: that's the problem with Java... too much XML ;)
206 [2008-08-29 15::22:27] pookey: however, that does mean that I'm slightly famialir with java's opinions of data tables
207 [2008-08-29 15::22:55] lvanderree: yep that is one of the problems
208 [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
209 [2008-08-29 15::23:05] » jcoby joined the chat room.
210 [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
211 [2008-08-29 15::23:15] lvanderree: sorting on foreign-fields can be done automatically when the generator is aware of foreign-fields
212 [2008-08-29 15::23:17] fabpot: bschussek: ok, I get it now
213 [2008-08-29 15::23:19] synace: the popup window uses list & filter
214 [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)
215 [2008-08-29 15::24:01] synace: (it's essentially a modification to list & filter for the foreign table, with an added object_action)
216 [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 ;)
217 [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
218 [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
219 [2008-08-29 15::24:34] fabpot: pookey: lol
220 [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
221 [2008-08-29 15::25:06] bschussek: synace: I agree. Actually this functionality belongs into the model
222 [2008-08-29 15::25:23] fabpot: pookey: yes, because you need lot of feature for a data grid to be useable
223 [2008-08-29 15::25:42] pookey: absolutly, it starts off seeming easy....
224 [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)
225 [2008-08-29 15::26:59] fabpot: lvanderree: yes, I was talking about single columns
226 [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
227 [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
228 [2008-08-29 15::28:47] fabpot: lvanderree: I understand, NiKo` has added this feature on the list
229 [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
230 [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
231 [2008-08-29 15::29:57] fabpot: lvanderree: ok for 1 and 2, 3 is a total different beast
232 [2008-08-29 15::30:18] lvanderree: true, but this makes it possible
233 [2008-08-29 15::31:31] synace: fabpot: so, in the feature list for list, filter, we have: foreign keys supported, yes?
234 [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
235 [2008-08-29 15::32:21] fabpot: synace: yes, that's the plan
236 [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)
237 [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)
238 [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
239 [2008-08-29 15::34:27] synace: fabpot: is there any way to provide filter & sort support for custom fields w/ the new architecture?
240 [2008-08-29 15::34:56] bschussek: lvanderree: considering drop downs with foreign key fields, there should be the possibility to sort them alphabetically
241 [2008-08-29 15::35:03] fabpot: synace: that's a nice to have feature
242 [2008-08-29 15::35:09] bschussek: be it in the filters, or in the edit view
243 [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
244 [2008-08-29 15::35:27] lvanderree: bschussek: yes that is what I (meant to) say
245 [2008-08-29 15::35:40] synace: bschussek: but i'd much rather see a user-controlled datagrid on one-to-many assignment
246 [2008-08-29 15::35:52] lvanderree: bschussek: I do that at the moment already in the sfExtjsTheme ;)
247 [2008-08-29 15::36:34] francoisz: did anyone talk about the ability for plugins to simply enhance the generator capabilities?
248 [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
249 [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
250 [2008-08-29 15::37:07] fabpot: synace: I'm not sure this is a good idea. For big tables, it's a nightmare
251 [2008-08-29 15::37:36] francoisz: fabpot: thanks
252 [2008-08-29 15::37:53] synace: fabpot: i think that the filter is an extension of the list though, presentation aside
253 [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)
254 [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
255 [2008-08-29 15::39:03] synace: fabpot: that seems right, filterListWidget extends filterWidget
256 [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?
257 [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)
258 [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
259 [2008-08-29 15::40:22] fabpot: francoisz: more decoupled means we will have more classes to extend from
260 [2008-08-29 15::40:42] bschussek: lvanderree: I think the presentation does not really depend on this architectural coupling
261 [2008-08-29 15::40:43] synace: francoisz: less spaghetti :)
262 [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.
263 [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
264 [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
265 [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
266 [2008-08-29 15::42:47] fabpot: francoisz: what do you mean?
267 [2008-08-29 15::43:11] francoisz: the 1.0 generator uses _list_header partials and so on
268 [2008-08-29 15::43:13] lvanderree: +1 for reusability, I mentioned that before
269 [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
270 [2008-08-29 15::44:16] fabpot: francoisz: ok, I understand
271 [2008-08-29 15::44:20] NiKo`: lvanderree: hey, I'm trying to do my best, just refresh the page now ;)
272 [2008-08-29 15::44:20] synace: francoisz: placeholders?
273 [2008-08-29 15::44:31] francoisz: synace: yes. slots are that
274 [2008-08-29 15::44:39] lvanderree: NiKo`: I don't have enough time ;)
275 [2008-08-29 15::44:41] francoisz: and events play the same role in controller/model classes
276 [2008-08-29 15::44:53] synace: francoisz: that's good, makes it easier to use existing code & not customize for simple additions
277 [2008-08-29 15::45:03] francoisz: synace: exactly
278 [2008-08-29 15::45:31] fabpot: francoisz: but where will you override the slot content for the listSuccess.php template for example?
279 [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
280 [2008-08-29 15::46:04] francoisz: fabpot: good question
281 [2008-08-29 15::46:10] lvanderree: francoisz: KRavEN has made a nice implementation for this as well (like slots)
282 [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
283 [2008-08-29 15::46:37] lvanderree: KRavEN made it possible to define partials in the generator.yml for the sfExtjsThemePlugin
284 [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?
285 [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?
286 [2008-08-29 15::47:01] fabpot: francoisz: right, the templates will be quite empty
287 [2008-08-29 15::47:55] francoisz: maybe empty partials are better than slots
288 [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)
289 [2008-08-29 15::48:39] fabpot: francoisz: what we need is multiple-inheritance for templates, like in Django
290 [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
291 [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
292 [2008-08-29 15::48:51] francoisz: fabpot: definitely :)
293 [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
294 [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
295 [2008-08-29 15::49:57] francoisz: note: I don't see any mention, in the "must have", of the new forms system?
296 [2008-08-29 15::50:35] fabpot: francoisz: lol
297 [2008-08-29 15::50:45] francoisz: also, "decoupled" should mean somehow using an adapter approach to make the generator transposable to Doctrine
298 [2008-08-29 15::52:34] fabpot: francoisz: yes, sfAdminManager
299 [2008-08-29 15::52:44] lvanderree: :D
300 [2008-08-29 15::53:08] francoisz: ok
301 [2008-08-29 15::53:25] lvanderree: although I wonder how much can be done before the 1.2 release in september?
302 [2008-08-29 15::54:11] francoisz: ah, a tough one:
303 [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
304 [2008-08-29 15::54:25] francoisz: at the moment, the generator allows to build up classes and modules
305 [2008-08-29 15::55:00] synace: francoisz: nav should be automatic based on modules, if enabled, but customizable via yml or db configuration
306 [2008-08-29 15::55:10] francoisz: synace: great
307 [2008-08-29 15::55:54] fabpot: nav should be automatic based on admin classes, not modules
308 [2008-08-29 15::55:58] lvanderree: probably also decoupled from representation somehow... since navigation is one of your keys for presentation
309 [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')
310 [2008-08-29 15::56:33] fabpot: francoisz: the trick here is that sfAdminManager knows sfAdmin objects and knows the associated routing
311 [2008-08-29 15::56:53] lvanderree: sounds good
312 [2008-08-29 15::57:02] synace: fabpot: adminmanager is akin to an enable plugin module then? (injects routes, etc..)
313 [2008-08-29 15::57:30] francoisz: fabpot: so sfAdminManager can import assets? I don't get it
314 [2008-08-29 15::58:15] synace: NiKo`: add to nicetohaves filterint n:m
315 [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
316 [2008-08-29 15::58:30] francoisz: fabpot: ah ok. I understood
317 [2008-08-29 15::58:38] fabpot: francoisz: what is the pbe with assets?
318 [2008-08-29 15::58:45] francoisz: I'm fine with doing that from admin classes
319 [2008-08-29 15::59:35] fabpot: francoisz: ok, but I don't see how we can overcome this limitation
320 [2008-08-29 15::59:54] francoisz: me neither, that's why I said it's a tough one :)
321 [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?
322 [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
323 [2008-08-29 16::01:30] fabpot: A theme is just a bunch of templates, right?
324 [2008-08-29 16::01:31] synace: fabpot: update the mod_rewrite rules and serve the assets through sf :lol:
325 [2008-08-29 16::01:40] francoisz: synace: lol
326 [2008-08-29 16::02:07] fabpot: ok, another question: what is a theme?
327 [2008-08-29 16::02:25] synace: francoisz: plugins put symlinks in web, why couldn't themes?
328 [2008-08-29 16::02:27] fabpot: for me, it's some templates that override the default ones
329 [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
330 [2008-08-29 16::02:40] fabpot: francoisz: ok
331 [2008-08-29 16::02:45] bschussek: fabpot: but also the images, css and js files associated with the templates, right?
332 [2008-08-29 16::02:48] lvanderree: representation + actions
333 [2008-08-29 16::03:01] synace: fabpot: i have 2 terms used to describe customization in my circa 2002 php4 framework
334 [2008-08-29 16::03:57] fabpot: lvanderree: the question is: is ExtJs or Flex support just a theme?
335 [2008-08-29 16::04:01] » roberto__ joined the chat room.
336 [2008-08-29 16::04:17] fabpot: lvanderree: if yes, then I'm with you, a theme is composed of templates and actions
337 [2008-08-29 16::04:18] lvanderree: fabpot: yep I see, that
338 [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
339 [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
340 [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'
341 [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
342 [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
343 [2008-08-29 16::06:17] lvanderree: fabpot: agree, not just a theme
344 [2008-08-29 16::06:49] francoisz: while we are speaking about style, I think the new generator should be sexy
345 [2008-08-29 16::06:58] bschussek: francoisz: absolutely agree
346 [2008-08-29 16::06:58] lvanderree: in my opinion a theme should be about representation only. So color, and arrangement of elements
347 [2008-08-29 16::07:08] francoisz: I mean, that's already a "Wow" factor for symfony
348 [2008-08-29 16::07:25] bschussek: although sexiness for me means also real usability
349 [2008-08-29 16::07:28] synace: francoisz: if it's gonna be sexy, it's gotto have fk's ;)
350 [2008-08-29 16::07:35] francoisz: bschussek: I'm with you on that
351 [2008-08-29 16::07:46] fabpot: francoisz: I'm with you on this one. The current one is just too ugly.
352 [2008-08-29 16::07:57] francoisz: synace: right. We may not share the same definition for sexy :)
353 [2008-08-29 16::08:01] synace: fabpot: i don't mind the look at all.. it's an admin panel
354 [2008-08-29 16::08:19] fabpot: synace: customer, IT managers, and new symfony developers care
355 [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)
356 [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
357 [2008-08-29 16::08:41] synace: every customer i have given it to loves it
358 [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
359 [2008-08-29 16::09:27] synace: i agree w/ bschussek: sexy = usability
360 [2008-08-29 16::09:33] fabpot: can we rename theme by skin? to be more exact on what we mean?
361 [2008-08-29 16::09:48] bschussek: francoisz: that was me. I based it on joyent, a real sexy application (= usable)
362 [2008-08-29 16::09:57] synace: fabpot: i like skin
363 [2008-08-29 16::10:22] bschussek: http://www.joyent.com/connector/collaboration-suite/screenshots/
364 [2008-08-29 16::10:26] francoisz: so maybe a nice to have feature would be: handle multiple skins natively - at least 2
365 [2008-08-29 16::11:01] lvanderree: but if we have skins, what are themes going to have?
366 [2008-08-29 16::11:07] fabpot: francoisz: propriatary
367 [2008-08-29 16::11:12] francoisz: damn
368 [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
369 [2008-08-29 16::11:31] francoisz: so we need a good designer to come up with a sexy skin
370 [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
371 [2008-08-29 16::11:52] francoisz: that's probably a nice to have feature, though
372 [2008-08-29 16::11:52] bschussek: we could ask the joyent designer
373 [2008-08-29 16::12:02] fabpot: bschussek: lol
374 [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 ;)
375 [2008-08-29 16::12:09] bschussek: :-)
376 [2008-08-29 16::12:48] francoisz: did anyone mention the ability to have a show view?
377 [2008-08-29 16::13:08] synace: i don't see a need
378 [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
379 [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
380 [2008-08-29 16::13:32] synace: though, it should be something possible. let's add it to must
381 [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
382 [2008-08-29 16::13:46] synace: +1
383 [2008-08-29 16::13:50] lvanderree: francoisz: nope, show view not seen +1 on that
384 [2008-08-29 16::13:51] francoisz: +1
385 [2008-08-29 16::13:56] synace: fabpot: allows us to build w/o waiting for a designer
386 [2008-08-29 16::14:28] francoisz: also, that may be too much, but can the admin manager handle security?
387 [2008-08-29 16::14:30] fabpot: actions + templates = module in symfony
388 [2008-08-29 16::15:14] lvanderree: true
389 [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
390 [2008-08-29 16::15:41] » klemens_ joined the chat room.
391 [2008-08-29 16::16:04] francoisz: synace: or bundle sfGuard with symfony and use it in the generator :)
392 [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
393 [2008-08-29 16::16:31] fabpot: Off Topic: What about bundling sfGuard with symfony 1.2?
394 [2008-08-29 16::16:31] francoisz: right
395 [2008-08-29 16::16:46] bschussek: +1
396 [2008-08-29 16::16:47] synace: +1
397 [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
398 [2008-08-29 16::17:00] synace: (it's easily removable and replaceable if that's the goal.. )
399 [2008-08-29 16::17:07] francoisz: (off topic: sfGuard+sfDoctrineGuard?)
400 [2008-08-29 16::17:07] bschussek: It's really just a DB implementation of the built-in credentials
401 [2008-08-29 16::17:09] synace: +1 if an interface is well defined in sfUser
402 [2008-08-29 16::17:23] klemens_: lvanderee: +1 especially the "readable"
403 [2008-08-29 16::17:35] synace: lvanderree: +1
404 [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
405 [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
406 [2008-08-29 16::18:25] synace: francoisz: +1000
407 [2008-08-29 16::18:25] francoisz: probably a nice to have feature
408 [2008-08-29 16::18:55] klemens_: that is also a requirement for the edit action of the admin generator
409 [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)
410 [2008-08-29 16::19:04] bschussek: francoisz: +1, such AJAX features are really necessary for a good usability (= sexiness again :-) )
411 [2008-08-29 16::19:19] » klemens_u left the chat room.
412 [2008-08-29 16::19:21] synace: that gives way to all the features i'm asking for in 1:n n:n
413 [2008-08-29 16::19:27] bschussek: that includes editing related records in form fields again, without having to leave the form
414 [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
415 [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?
416 [2008-08-29 16::19:38] » jamiel joined the chat room.
417 [2008-08-29 16::19:48] francoisz: ok, then we can use pure js then :)
418 [2008-08-29 16::19:53] fabpot: francoisz: lol
419 [2008-08-29 16::20:14] synace: fabpot: that limits us greatly.... why not just bundle jquery w/ noConflict ;)
420 [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
421 [2008-08-29 16::20:16] bschussek: actually we could release a javascript plugin that unobstrusively adds these features
422 [2008-08-29 16::20:27] fabpot: bschussek: +1
423 [2008-08-29 16::20:32] synace: francoisz: volunteered :)
424 [2008-08-29 16::20:39] francoisz: whatwhatwhat?
425 [2008-08-29 16::20:41] synace: bschussek: +++
426 [2008-08-29 16::20:52] klemens_: bschussek: yes punobstrusively, definitly
427 [2008-08-29 16::20:53] synace: exactly!
428 [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
429 [2008-08-29 16::21:18] bschussek: this could, again, rely on a javascript library and can be ported to different libraries
430 [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
431 [2008-08-29 16::21:31] synace: bschussek: yes, but that's problematic
432 [2008-08-29 16::21:48] bschussek: synace: you mean because of admin generator extensions?
433 [2008-08-29 16::21:52] synace: yes
434 [2008-08-29 16::21:55] bschussek: I agree
435 [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?
436 [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
437 [2008-08-29 16::22:27] synace: francoisz: popup?
438 [2008-08-29 16::22:42] francoisz: ah
439 [2008-08-29 16::22:43] bschussek: synace: i personally hate popups
440 [2008-08-29 16::22:48] synace: it can easily do stuff w/ native js and popup and simple html rewrites
441 [2008-08-29 16::22:48] francoisz: bschussek: me too
442 [2008-08-29 16::23:02] synace: bschussek: can we do DHTML layers?
443 [2008-08-29 16::23:05] francoisz: damn, its 2008, guys
444 [2008-08-29 16::23:06] bschussek: a javascript simple roll out can do as well
445 [2008-08-29 16::23:27] francoisz: fabpot: don't make fun of me
446 [2008-08-29 16::23:32] lvanderree: isn't this what extjs is doing ;)
447 [2008-08-29 16::23:33] synace: bschussek: i'm actually using iframes for my relational tool ;) w/ js polling and auto-resize
448 [2008-08-29 16::23:35] fabpot: francoisz: sorry :|
449 [2008-08-29 16::23:36] synace: lvanderree: yes
450 [2008-08-29 16::23:42] francoisz: fabpot: or I'll make fun of you when you end up using my stuff
451 [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
452 [2008-08-29 16::24:32] francoisz: synace: right
453 [2008-08-29 16::24:49] bschussek: francoisz: well done on the DbFinder, by the way ;-) (sorry for going off topic)
454 [2008-08-29 16::25:03] francoisz: bschussek: WAY off topic, but thanks
455 [2008-08-29 16::25:03] lvanderree: he deserves the credtis
456 [2008-08-29 16::25:33] synace: since we're off-topic: when we redoing sf in php5.3 ;)
457 [2008-08-29 16::25:38] fabpot: the question is: will we be able to unobstrusively add Ajax stuff on the default templates?
458 [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
459 [2008-08-29 16::25:55] synace: fabpot: it depends on our implementation of the controllers..
460 [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
461 [2008-08-29 16::26:24] jamiel: Whos going to make us some new buttons ...
462 [2008-08-29 16::26:29] lvanderree: synace: agree, depends on controller
463 [2008-08-29 16::26:29] bschussek: francoisz: actually, a thing like DbFinder, but for javascript libraries, should be possible, shouldn't it?
464 [2008-08-29 16::26:42] francoisz: bschussek: what, you want to write it?
465 [2008-08-29 16::26:54] lvanderree: hehe
466 [2008-08-29 16::26:58] bschussek: erm ... no :-) I really am not that experienced with javascript
467 [2008-08-29 16::27:05] francoisz: I think using jQuery with compat mode is the best choice
468 [2008-08-29 16::27:34] synace: mit also
469 [2008-08-29 16::27:34] fabpot: francoisz: I agree with the jQuery choice but what about people wanting to use YUI or prototype?
470 [2008-08-29 16::27:46] lvanderree: ExtJs has adapters to support different javascript frameworks, but I never touched them
471 [2008-08-29 16::27:46] francoisz: another skin
472 [2008-08-29 16::27:55] synace: jquery/yui/ext all get along
473 [2008-08-29 16::28:02] francoisz: synace: how?
474 [2008-08-29 16::28:06] NiKo`: I think we should not bundle a given js lib with symfony
475 [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
476 [2008-08-29 16::28:18] synace: NiKo`: agreed
477 [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)
478 [2008-08-29 16::28:42] francoisz: so basically, that brings us back to the former statement: no js in the default theme?
479 [2008-08-29 16::28:48] NiKo`: furthermore, I think a lot of unobstrusive ajaxification can be done in a separated js file
480 [2008-08-29 16::28:58] lvanderree: and have a skin for every framework
481 [2008-08-29 16::29:19] synace: lvanderree: sure, sf builds one w/ jquery to start
482 [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?
483 [2008-08-29 16::29:24] synace: and then, it can be replaced w/ another one
484 [2008-08-29 16::29:31] » klemens_ left the chat room.
485 [2008-08-29 16::29:40] bschussek: fabpot: you mean without any libraries?
486 [2008-08-29 16::29:44] fabpot: we can bundled the needed actions for Ajax
487 [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?
488 [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
489 [2008-08-29 16::30:18] fabpot: francoisz: this means that we need to provide an implementatino for every single library out there?
490 [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
491 [2008-08-29 16::30:34] francoisz: fabpot: just the ones we want to support
492 [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
493 [2008-08-29 16::30:52] francoisz: fabpot: and maybe just one, and we live the others to whoever wants to write them
494 [2008-08-29 16::30:53] synace: francoisz/fabpot, it's the same issue (and should be same resolution) as doctrine/propel
495 [2008-08-29 16::31:14] francoisz: I agree with synace
496 [2008-08-29 16::31:25] fabpot: synace: more or less. we only have 2 ORMs in PHP. There are 10 great JavaScript libraries
497 [2008-08-29 16::31:25] francoisz: don't give users too much choice at the beginning
498 [2008-08-29 16::31:30] NiKo`: to me, all of these js-libraries-coupled stuff should be done in externals plugins
499 [2008-08-29 16::31:33] francoisz: choice is the ennemy of usability
500 [2008-08-29 16::31:33] synace: francoisz: exactly
501 [2008-08-29 16::31:40] NiKo`: core should just provide default ajax-enabled actions
502 [2008-08-29 16::31:41] bschussek: I agree
503 [2008-08-29 16::31:47] synace: francoisz: the linux syndrome.. way too much choice (the mythtv syndrome!!)
504 [2008-08-29 16::31:48] fabpot: jQuery, mootools, Dojo, YUI, prototype, ...
505 [2008-08-29 16::31:57] synace: NiKo`: +
506 [2008-08-29 16::32:26] francoisz: NiKo`: and end up writing Yet Another Js Lib?
507 [2008-08-29 16::32:28] synace: fabpot: yahoo doesn't even use doctrine/propel
508 [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
509 [2008-08-29 16::32:35] francoisz: NiKo`: not sure it's the best idea
510 [2008-08-29 16::32:36] synace: which suffice to say, they don't use the admin generator
511 [2008-08-29 16::32:44] NiKo`: francoisz: core should not contain one line of js to me
512 [2008-08-29 16::32:51] synace: bschussek: true
513 [2008-08-29 16::33:01] NiKo`: except if(confirm('Sure?'))
514 [2008-08-29 16::33:08] francoisz: NiKo`: ah, just actions, right
515 [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
516 [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
517 [2008-08-29 16::33:23] synace: and make that the 'default' choice
518 [2008-08-29 16::33:28] NiKo`: yep. You want Propel2JSON output ? sf_format is there for that
519 [2008-08-29 16::33:44] bschussek: lvanderree: It should be bundled as plugin though
520 [2008-08-29 16::33:45] synace: lvanderree: negative, the js needs to be a plugin from the start
521 [2008-08-29 16::34:06] francoisz: NiKo`: actions without templates, that don't work out of the box?
522 [2008-08-29 16::34:07] synace: francoisz: will agree that it needs to be bundled by default though
523 [2008-08-29 16::34:07] bschussek: but you could provide the hooks for the plugins by default
524 [2008-08-29 16::34:23] lvanderree: bschussek/synace: sorry meant that, one plugin with one framework, but natively supported...
525 [2008-08-29 16::34:30] bschussek: +1
526 [2008-08-29 16::34:31] synace: bschussek: some.. probably not all.. the plugin should provide a custom class extension of the base classes
527 [2008-08-29 16::34:47] jcoby: have helpers been discussed yet?
528 [2008-08-29 16::34:51] synace: ex: yourAdminClass extends sfAdmin... becomes: yourAdminClass extends sfJqueryAdmin
529 [2008-08-29 16::35:19] francoisz: back to some features: how about credentials on columns display?
530 [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...
531 [2008-08-29 16::35:34] synace: the js plugins have to provide specialization and theme, not just theme
532 [2008-08-29 16::35:58] fabpot: francoisz: already added with 3 states: read-only, not-displayed, editable
533 [2008-08-29 16::36:11] francoisz: fabpot: great
534 [2008-08-29 16::36:57] synace: fabpot: want to summarize admin & js implementation?
535 [2008-08-29 16::37:04] francoisz: a small feature: can the wildcard be automatic in text filters?
536 [2008-08-29 16::37:12] synace: francoisz: +1
537 [2008-08-29 16::37:25] bschussek: I think it already is, isn't it?
538 [2008-08-29 16::37:33] francoisz: bschussek: nope
539 [2008-08-29 16::37:42] fabpot: francoisz: ok, Google style
540 [2008-08-29 16::37:43] synace: not inline
541 [2008-08-29 16::38:15] jcoby: francoisz: being able to type in part of an email to find a user would be nice
542 [2008-08-29 16::38:16] synace: francoisz: example: 'callout' search: cal%t
543 [2008-08-29 16::38:17] bschussek: fabpot: +1 most users are used to Google
544 [2008-08-29 16::38:18] synace: works
545 [2008-08-29 16::38:20] francoisz: not inline, but if I serach for 'fab' I should find 'fabpot' and 'potfab'
546 [2008-08-29 16::38:26] synace: francoisz: it does for me
547 [2008-08-29 16::38:42] francoisz: synace: I had to override the default them to add that!
548 [2008-08-29 16::38:54] synace: francoisz: i don't think i did.. :/
549 [2008-08-29 16::38:57] francoisz: synace: you probably did somethog in the actions class
550 [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)
551 [2008-08-29 16::39:27] synace: francoisz: negatory.. this is a low-budget admin build ;)
552 [2008-08-29 16::39:39] francoisz: synace: there you have it
553 [2008-08-29 16::39:40] synace: jcoby: francoisz: doctrine or propel?
554 [2008-08-29 16::39:47] jcoby: synace: propel
555 [2008-08-29 16::39:49] francoisz: synace: those Doctrine guys are so way ahead ;)
556 [2008-08-29 16::40:04] bschussek: we should provide a tree data grid by default for displaying nested sets
557 [2008-08-29 16::40:06] synace: yeah, wage is doing a great job.. i was trying to hire him before fabien did ;)
558 [2008-08-29 16::40:11] francoisz: bschussek: !
559 [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 ;)
560 [2008-08-29 16::40:36] francoisz: bschussek: nice to have feature, but greatly depends on how you implement the nested sets
561 [2008-08-29 16::40:47] synace: bschussek: plugin
562 [2008-08-29 16::40:58] bschussek: francoisz: unfortunately yes
563 [2008-08-29 16::41:08] NiKo`: bschussek: this could be a widget
564 [2008-08-29 16::41:09] synace: francoisz: users expect this type of stuff out of the box
565 [2008-08-29 16::41:21] NiKo`: bschussek: but I cannot see it as a core widget
566 [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?
567 [2008-08-29 16::41:38] synace: NiKo`: plugin widget
568 [2008-08-29 16::42:04] francoisz: I mean, from the generator.yml
569 [2008-08-29 16::42:12] synace: yeah, add peerMethod support to filters
570 [2008-08-29 16::42:33] francoisz: (or womething else: see how DbFinder generator allows 'model filters' to be added to any query)
571 [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
572 [2008-08-29 16::43:04] fabpot: francoisz: added to the list
573 [2008-08-29 16::43:15] francoisz: also, the ability to define the list of options for a filter amnually in the generator.yml
574 [2008-08-29 16::43:27] synace: that's really a field type
575 [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"
576 [2008-08-29 16::43:59] synace: bschussek: i think it's one field
577 [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
578 [2008-08-29 16::44:06] synace: abstracted to display as 2 in the partial
579 [2008-08-29 16::44:15] bschussek: synace: I agree, but how would one implement it?
580 [2008-08-29 16::44:28] francoisz: fabpot: if the generator.yml gives a simple way to do that, fine :)
581 [2008-08-29 16::44:28] bschussek: reusable, with sfForm
582 [2008-08-29 16::44:28] fabpot: bschussek: you mean, a GMaps widget
583 [2008-08-29 16::44:29] jcoby: synace: every implementation of lat/lon pairs i've ever seen has been two columns
584 [2008-08-29 16::44:38] bschussek: fabpot: yes
585 [2008-08-29 16::44:46] synace: jcoby: then we need support for multiple fields w/ 1 label
586 [2008-08-29 16::44:55] fabpot: bschussek: looks like easy to do
587 [2008-08-29 16::45:05] synace: jcoby: which is possible w/ partials.. which will be possible w/ the new admin classes
588 [2008-08-29 16::45:08] francoisz: also a nice to have feature, if we have an sfAdminManager to hadle side menus: a breadcrumb
589 [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
590 [2008-08-29 16::45:24] francoisz: And the ability to nest admin modules
591 [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.
592 [2008-08-29 16::45:36] fabpot: jcoby: not a problem, you have one widget but 2 validators
593 [2008-08-29 16::46:04] jcoby: fabpot: ahh, ok
594 [2008-08-29 16::46:08] bschussek: fabpot: and where do you put the logic for the custom address polling?
595 [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
596 [2008-08-29 16::46:52] francoisz: also: can the peerMethod used for the list depend on the credentials?
597 [2008-08-29 16::46:52] fabpot: bschussek: I don't understand the question
598 [2008-08-29 16::47:01] francoisz: or should that be implemented in the model (brr)
599 [2008-08-29 16::47:06] synace: francoisz: hrm
600 [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.
601 [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
602 [2008-08-29 16::48:07] synace: i suppose it could be done in the configuration
603 [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
604 [2008-08-29 16::49:01] fabpot: bschussek: all this features must be included in the widget
605 [2008-08-29 16::49:11] jcoby: bschussek: then you're going to be getting into localization problems.
606 [2008-08-29 16::49:23] bschussek: fabpot: exactly
607 [2008-08-29 16::49:24] francoisz: another nice to have feature: next/prev buttons in the edit/show view
608 [2008-08-29 16::49:41] synace: francoisz: by sorting in list view used to get to this edit page
609 [2008-08-29 16::49:53] francoisz: synace: naturally
610 [2008-08-29 16::50:01] jcoby: francoisz: agreed.
611 [2008-08-29 16::50:04] bschussek: fabpot: but the widget doesn't include the validators, does it`
612 [2008-08-29 16::50:15] synace: i wouldn't say it does bschussek
613 [2008-08-29 16::50:17] fabpot: bschussek: no
614 [2008-08-29 16::50:21] bschussek: and that's the problem
615 [2008-08-29 16::50:29] fabpot: bschussek: why?
616 [2008-08-29 16::50:38] synace: bschussek: admin mixins?
617 [2008-08-29 16::50:48] fabpot: bschussek: as it's a bit offtopic, we can talk about that later
618 [2008-08-29 16::51:07] bschussek: fabpot: I agree. I just thougth this might affect the features of the generator
619 [2008-08-29 16::51:08] jcoby: feature i'd like to see: automatic hiding of lazy load columns in the view action.
620 [2008-08-29 16::51:40] synace: jcoby: if no field list specified?
621 [2008-08-29 16::51:46] jcoby: synace: yes
622 [2008-08-29 16::52:09] synace: jcoby: i would say no lazyload by default in list
623 [2008-08-29 16::52:17] jcoby: synace: right, sorry, i meant list
624 [2008-08-29 16::52:19] brankgnol_: hope NiKo didn't missed francoisz last resquest.. :)
625 [2008-08-29 16::52:28] synace: gotcah
626 [2008-08-29 16::52:33] francoisz: brankgnol_: no, he didn't. I check the wiki page :)
627 [2008-08-29 16::52:40] NiKo`: brankgnol_: nope, it's been added on the page
628 [2008-08-29 16::53:03] francoisz: NiKo`: yes
629 [2008-08-29 16::53:05] brankgnol_: :)
630 [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
631 [2008-08-29 16::53:13] » jvdlaan left the chat room.
632 [2008-08-29 16::53:27] synace: if they need JS, they would require the jsAdmin plugin
633 [2008-08-29 16::54:03] jcoby: what do you think about adding admin attributes to the model like django?
634 [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) ?
635 [2008-08-29 16::54:34] bschussek: jcoby: isn't this a quuestion of the ORM?
636 [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
637 [2008-08-29 16::55:26] synace: what was our conclusion on JS-ified admin?
638 [2008-08-29 16::55:47] francoisz: synace: the wiki page says: no js
639 [2008-08-29 16::55:48] » shawncplus joined the chat room.
640 [2008-08-29 16::55:53] lvanderree: :S I was away for maybe 5 minutes, took my 10 minutes to read this all :D
641 [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
642 [2008-08-29 16::56:09] synace: francoisz: i though we were doing a plugin bundled & enabled by default, but replaceable ?
643 [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
644 [2008-08-29 16::57:02] francoisz: synace: unobtrusive Ajax/effects, depending on a library, added afterwards?
645 [2008-08-29 16::57:11] synace: francoisz: yes, but bundled
646 [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
647 [2008-08-29 16::57:41] synace: francoisz: no, the plugin will bundle the js lib
648 [2008-08-29 16::57:49] francoisz: synace: bad idea
649 [2008-08-29 16::57:50] synace: or require the appropriate js plugin that does
650 [2008-08-29 16::57:58] francoisz: synace: better idea :)
651 [2008-08-29 16::58:08] synace: i come up w/ them all day ;)
652 [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
653 [2008-08-29 16::58:46] synace: decoupled, easily replaced
654 [2008-08-29 16::59:16] francoisz: fabpot: what's your opinion on that?
655 [2008-08-29 16::59:39] synace: we were also talking about bundling sfGuard
656 [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.
657 [2008-08-29 17::00:13] lvanderree: isn't it possible to bundle the sfFinder plugin, to make it ORM independed?
658 [2008-08-29 17::00:17] fabpot: francoisz: I really think we don't want to bundle a JS library
659 [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
660 [2008-08-29 17::00:36] jcoby: bschussek: yeah.. that's how django works :)
661 [2008-08-29 17::00:41] NiKo`: to me, +1 bundling sfGuard, -1 for bundling any js lib/framework
662 [2008-08-29 17::00:42] francoisz: fabpot: then we forget the sexy skin
663 [2008-08-29 17::00:59] synace: francoisz: exactly.. we also forget tons of usability
664 [2008-08-29 17::01:07] fabpot: francoisz: is the Django admin sexy?
665 [2008-08-29 17::01:14] brankgnol_: NiKo +1
666 [2008-08-29 17::01:20] francoisz: fabpot: more than symfony's :)
667 [2008-08-29 17::01:21] synace: fabpot: no... it's limited in functionality
668 [2008-08-29 17::01:25] fabpot: francoisz: and no JS
669 [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
670 [2008-08-29 17::01:50] NiKo`: francoisz: ajax doesn't mean useable, oftem it's quite the opposite
671 [2008-08-29 17::01:57] synace: fabpot: what's the ultimate priority of sexy: visual look, or functionality & usability?
672 [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
673 [2008-08-29 17::02:05] jcoby: bschussek: right. which is why RoR and django both do model-level validation.
674 [2008-08-29 17::02:10] francoisz: NiKo`: sure we can come up with something usable
675 [2008-08-29 17::02:29] bschussek: jcoby: awesome. but let's keep that for later maybe and stay on one topic :-)
676 [2008-08-29 17::02:35] synace: bschussek: that's a different topic altogether, but a very very good one
677 [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
678 [2008-08-29 17::02:53] synace: francoisz: exactly
679 [2008-08-29 17::02:58] lvanderree: about model validation +1 for that, just like credential checking at model level, instead of module
680 [2008-08-29 17::02:59] synace: which is why i would like it bundled
681 [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?
682 [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
683 [2008-08-29 17::03:37] synace: jcoby: i have a customized module of sfGuardAdmin->profile that does all that it's pretty easy
684 [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
685 [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.
686 [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
687 [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)
688 [2008-08-29 17::04:58] bschussek: francoisz: https://customer.joyent.com/signup/customer
689 [2008-08-29 17::05:06] francoisz: synace: NiKo` and fabpot say no, I won't argue
690 [2008-08-29 17::05:57] fabpot: ok, it's 17:00. I will have to left in about 15 minutes...
691 [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)
692 [2008-08-29 17::06:18] bschussek: what about tabs in edit views? (js again, I know)
693 [2008-08-29 17::06:47] lvanderree: I like the idea of validation and credential checking on model level, instead of module level
694 [2008-08-29 17::06:58] jcoby: bschussek: seems like a minor extension to the current groupings?
695 [2008-08-29 17::06:58] bschussek: and one last big topic: proper support of I18N!
696 [2008-08-29 17::07:00] » mysyfy_ joined the chat room.
697 [2008-08-29 17::07:01] » mysyfy left the chat room.
698 [2008-08-29 17::07:08] fabpot: bschussek: what for? to replace the existing sections?
699 [2008-08-29 17::07:25] bschussek: easier navigation on long edit pages
700 [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
701 [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
702 [2008-08-29 17::08:29] bschussek: synace: I disagree, if the save button is clearly placed outside of the tabbed area
703 [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
704 [2008-08-29 17::09:01] lvanderree: bschussek: I agree on that :) clearly visible save button fixes trhat
705 [2008-08-29 17::09:20] » rafix joined the chat room.
706 [2008-08-29 17::09:43] bschussek: silverstripe is a good example for that: http://demo.silverstripe.com/
707 [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
708 [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!
709 [2008-08-29 17::09:51] lvanderree: But I haven't seen a good argument not to bundle it by the way
710 [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
711 [2008-08-29 17::10:52] bschussek: so what about I18N?
712 [2008-08-29 17::11:00] fabpot: bschussek: added to the list
713 [2008-08-29 17::11:03] francoisz: bschussek: handled by sfForms
714 [2008-08-29 17::11:08] bschussek: indeed?
715 [2008-08-29 17::11:14] fabpot: bschussek: yes
716 [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.
717 [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
718 [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)
719 [2008-08-29 17::11:54] francoisz: is easy handling of file columns a feature we wish?
720 [2008-08-29 17::12:05] jcoby: francoisz: yes
721 [2008-08-29 17::12:13] fabpot: francoisz: yes
722 [2008-08-29 17::12:40] jcoby: ideally with in-database and out-of-database storage
723 [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
724 [2008-08-29 17::12:46] synace: francoisz: widget
725 [2008-08-29 17::12:49] fabpot: bschussek: yes
726 [2008-08-29 17::13:05] bschussek: fabpot: great, then I'm happy :-)
727 [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
728 [2008-08-29 17::13:27] synace: lvanderree: off topic, but +10,000
729 [2008-08-29 17::13:32] bschussek: lvanderree: I absolutely would like that, but it's ORM related
730 [2008-08-29 17::13:34] jcoby: lvanderree: let's move that to sf-devs
731 [2008-08-29 17::13:34] » k88 joined the chat room.
732 [2008-08-29 17::13:41] » saganxis joined the chat room.
733 [2008-08-29 17::13:47] francoisz: lvanderree: -1 for me
734 [2008-08-29 17::13:48] lvanderree: but it is related to the generator
735 [2008-08-29 17::13:49] fabpot: lvanderree: the problem is that we use externals libraries for the model, Propel or Doctrine
736 [2008-08-29 17::14:01] jcoby: lvanderree: i was going to start an email on it in a bit
737 [2008-08-29 17::14:19] fabpot: lvanderree: but let's discuss that on the dev ML if you want
738 [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
739 [2008-08-29 17::14:33] lvanderree: fabpot: I see, maybe an extra generator to do this outside the module level?
740 [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
741 [2008-08-29 17::15:08] synace: francoisz: you gonna be working on the sfJSAdmin ?
742 [2008-08-29 17::15:32] » gnat42 joined the chat room.
743 [2008-08-29 17::15:33] lvanderree: fabpot: OK good, And I will start a thread/post in the ML
744 [2008-08-29 17::15:41] francoisz: synace: er... dunno
745 [2008-08-29 17::15:47] » silvain left the chat room.
746 [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
747 [2008-08-29 17::16:22] synace: NiKo`: thx for making js-potential-support must have
748 [2008-08-29 17::16:49] NiKo`: synace: if it's potential, it can't be a must have...
749 [2008-08-29 17::16:51] gnat42: was this conversation logged sompleace?
750 [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
751 [2008-08-29 17::17:05] lvanderree: maybe it is wise to sleep/think a weekend about all what has been said
752 [2008-08-29 17::17:07] NiKo`: gnat42: yes, log will be attached to the wiki page
753 [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"
754 [2008-08-29 17::17:32] gnat42: NiKo`: thanks
755 [2008-08-29 17::17:40] bschussek: fabpot: ok. where can we continue the discussion of the details and the distribution of work? ML?
756 [2008-08-29 17::17:41] lvanderree: define some real requirements from the points summarised in the wiki and meet again after that
757 [2008-08-29 17::17:56] fabpot: bschussek: right, let's talk about people wanting to help
758 [2008-08-29 17::18:21] francoisz: I think someone is calling me on the other line
759 [2008-08-29 17::18:25] bschussek: I do
760 [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?
761 [2008-08-29 17::18:38] fabpot: Ok, let's add the names on the wiki page
762 [2008-08-29 17::18:58] francoisz: I can help with the doc ;)
763 [2008-08-29 17::19:31] fabpot: synace: I want to release 1.2 alpha in October... I know, it will come very fast ;)
764 [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
765 [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
766 [2008-08-29 17::20:04] francoisz: fabpot: how about the generator.yml syntax?
767 [2008-08-29 17::20:12] fabpot: I will work on the basic architecture, the base classes, ... to ease the contributions
768 [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 :-)
769 [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
770 [2008-08-29 17::20:52] lvanderree: OK, maybe we can both take a look at it, after I have optimised the Propel version
771 [2008-08-29 17::21:16] fabpot: so, I will create an admin-gen branch from 1.2
772 [2008-08-29 17::21:25] lvanderree: I think we first need a base for the Php config
773 [2008-08-29 17::21:34] francoisz: ah ok
774 [2008-08-29 17::21:41] fabpot: and I will grant access to people willing to help
775 [2008-08-29 17::21:52] synace: NiKo`: 2 edits
776 [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
777 [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.."
778 [2008-08-29 17::22:31] bschussek: fabpot: rgr. how are we going to coordinate the work?
779 [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
780 [2008-08-29 17::23:01] NiKo`: BTW, what about backward compatibility between old admin gen and the upcoming one ?
781 [2008-08-29 17::23:02] bschussek: fabpot: ok
782 [2008-08-29 17::23:10] NiKo`: (hint: we're on a 1.x branch)
783 [2008-08-29 17::23:31] synace: fabpot: off-topic: sensio uses scrum i take it?
784 [2008-08-29 17::23:55] bschussek: NiKo`: we could generate the generator configuration based on the generator.yml (wow...)
785 [2008-08-29 17::23:59] francoisz: NiKo`: there is a class name on top of the generator.yml
786 [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
787 [2008-08-29 17::24:25] francoisz: NiKo`: we need to ship the old classes and name the new generator differently
788 [2008-08-29 17::24:44] synace: fabpot: fork w/ both available in 1.2, remove old in 1.3?
789 [2008-08-29 17::24:44] francoisz: (not like validator classes in pre-1.0)
790 [2008-08-29 17::25:24] » roberto__ left the chat room.
791 [2008-08-29 17::25:26] » jcoby_ joined the chat room.
792 [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
793 [2008-08-29 17::25:50] francoisz: I meant pre-1.1
794 [2008-08-29 17::25:57] synace: rgr
795 [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
796 [2008-08-29 17::26:06] » sf___ joined the chat room.
797 [2008-08-29 17::26:15] fabpot: francoisz: it was fixed before the release of 1.1 ;)
798 [2008-08-29 17::26:29] lvanderree: I say remove sfCompat10
799 [2008-08-29 17::26:33] synace: +1 remove
800 [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 ?
801 [2008-08-29 17::26:45] » roberto__ joined the chat room.
802 [2008-08-29 17::26:49] fabpot: francoisz: lol
803 [2008-08-29 17::26:56] synace: francoisz: on this release cycle & w/ propel still bundled: no
804 [2008-08-29 17::26:56] NiKo`: francoisz: you're my troll-hero \o/
805 [2008-08-29 17::27:04] » sf___ is now known as sf.
806 [2008-08-29 17::27:10] francoisz: NiKo`: it takes years to learn
807 [2008-08-29 17::27:15] NiKo`: (but this makes sense indeed)
808 [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
809 [2008-08-29 17::27:31] fabpot: that makes sense
810 [2008-08-29 17::27:54] synace: what's preventing pulling propel now then?
811 [2008-08-29 17::28:18] lvanderree: at least 1.6 ;) rounds to 2.0
812 [2008-08-29 17::28:33] synace: new people to sf 2.0 should then have no question of what to use..
813 [2008-08-29 17::28:36] francoisz: but that also means that upgrading from 1.1 won't be possible
814 [2008-08-29 17::29:04] fabpot: francoisz: as far as the admin gen. is concerned, well, yes
815 [2008-08-29 17::29:06] synace: i didn't say: don't update propel, i just meant: don't ship probel
816 [2008-08-29 17::29:21] francoisz: so, in "nice to have", I think symfony 1.0 generator.yml compatibility should figure
817 [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
818 [2008-08-29 17::29:56] synace: francoisz: then you need sfCompat10 and everything else
819 [2008-08-29 17::29:57] » k88 left the chat room.
820 [2008-08-29 17::30:00] synace: +1 NiKo`
821 [2008-08-29 17::30:06] francoisz: NiKo`: I agree. But that would be quite deceptive for those who started in 1.1
822 [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...
823 [2008-08-29 17::30:30] NiKo`: francoisz: I agree :/
824 [2008-08-29 17::30:40] bschussek: fabpot: see you! thanks for the nice meeting
825 [2008-08-29 17::30:43] fabpot: Perhaps we need to keep sfCompat10 in sf1.2
826 [2008-08-29 17::30:50] synace: francoisz: branch!
827 [2008-08-29 17::30:58] francoisz: synace: are you crazy?
828 [2008-08-29 17::31:03] synace: yes ;)
829 [2008-08-29 17::31:11] » fabpot left the chat room.