Wiki source code of IRC Archive for channel #xwiki

Last modified by Vincent Massol on 2012/10/18 19:11

Show last authors
1 jvdrean joined #xwiki at 00:13
2 vmassol - (00:15): jvelociter: hi, I don't understand the need for your noscript macro
3 jvdrean left #xwiki at 00:15
4 vmassol - (00:15): what's the difference with {{{…}}} for example?
5 vmassol - (00:16): ok I think I see
6 vmassol - (00:16): it executes everything except script macros
7 vmassol - (00:17): I'm still curious to understand why a combination of {{{…}}} and standard wiki syntax wouldn't work
8 vmassol - (00:17): maybe you're doing some {{include}} and don't fully control its content
9 vmassol - (00:18): or something like this
10 vmassol - (00:18): :)
11 vmassol left at 00:34 (Quit: Leaving.
12 Denis left at 07:04 (Ping timeout: 276 seconds
13 Denis joined #xwiki at 07:10
14 mflorea joined #xwiki at 07:23
15 Denis1 joined #xwiki at 07:39
16 Denis left at 07:41 (Ping timeout: 276 seconds
17 vmassol joined #xwiki at 07:45
18 kibahop joined #xwiki at 07:48
19 kibahop left #xwiki at 08:22
20 npm left at 08:41 (Quit: Leaving.
21 npm joined #xwiki at 08:43
22 Denis1 is now known as Denis ([email protected]
23 tmortagne joined #xwiki at 09:22
24 Enygma` joined #xwiki at 09:22
25 lucaa left at 09:27 (Quit: Leaving.
26 evalica joined #xwiki at 09:29
27 silviar joined #xwiki at 09:30
28 jvelociter - (09:37): Hi vmassol . Re the noscript macro, I actually don't have a need for it. I wrote it as an exercice in a developer training session. Though I see one use case, which I describe on the macro page : when you have user input (or other external) input in syntax 2.0 (for example let say comments on pages)
29 jvelociter - (09:38): (it should not be needed ideally, but with our current programming right model, it would be to be real safe, since you can't predict a page is or is not saved with programming rights)
30 CalebJamesDeLisl - (09:38): jvelociter: That's cool, do you handle possibilities like onclick=?
31 jvelociter - (09:39): CalebJamesDeLisl: actually it's no JSR223 {{script}} :)
32 jvelociter - (09:39): but we could forbid HTML easily, too
33 CalebJamesDeLisl - (09:39): Ahh yes, I forgot.
34 jvelociter - (09:39): forbidding just <script> might be a bit trickier
35 vmassol - (09:41): jvelociter: ok thanks. That's the only use case I could find too.
36 CalebJamesDeLisl - (09:41): Ahh, there's more than just <script> :( http://jira.xwiki.org/jira/browse/XWIKI-4874
37 jvelociter - (09:41): vmassol: there is another one though
38 jvelociter - (09:42): for the case you have a lot of external input, and that you display say in a table. You are lazy and don;t want verbatim in all cells :)
39 jvelociter - (09:42): (but that's not good practice one could argue)
40 CalebJamesDeLisl - (09:44): I've been feeling down about our security policy. All of this secrecy seems to be hurting the efficiency of fixing the problems.
41 vmassol - (09:44): external mixed input is the use case indeed
42 vmassol - (09:44): CalebJamesDeLisl: yes we need to revisit it
43 jvelociter - (09:45): xipe could not agree more I believe :)
44 CalebJamesDeLisl - (09:45): Perfect example is http://jira.xwiki.org/jira/browse/XWIKI-4755 I think we can only fix this with a character filter which gives up the secret.
45 jvelociter - (09:46): well at some points the commits give up the secret anyway
46 CalebJamesDeLisl - (09:46): In some cases we can rewrite things and hide it, but sometimes we just can't.
47 CalebJamesDeLisl - (09:47): Also I think we need to synchronize with the Hibernate folks since 4755 is really their issue.
48 tmortagne left at 09:55 (Remote host closed the connection
49 tmortagne joined #xwiki at 09:56
50 KermitTheFragger joined #xwiki at 10:00
51 lucaa joined #xwiki at 10:03
52 glerouge joined #xwiki at 10:05
53 vmassol - (10:05): mflorea: haven't read it but maybe this is useful to us: http://www.infoq.com/articles/gwt_unit_testing ?
54 vmassol - (10:06): (or maybe not)
55 gvallarelli joined #xwiki at 10:16
56 gvallarelli - (10:16): Hi XWikiers!
57 CalebJamesDeLisl - (10:17): Hi gvallarelli
58 mflorea - (10:21): vmassol: it's an interesting article, but I'm not convinced their approach is suitable when you have lots of browser specific code (and it's not always a matter of choice when you deal with JavaScript). They say they rewrite the native methods (=JavaScript code) in Java but I'm not sure this is possible for all the custom IE API I'm using to make the editor work as in FF. Sooner or latter you have to run the tests in the environment, i.e. in the browser. Fro
59 vmassol - (10:21): do we have a strategy right now?
60 vmassol - (10:21): for testing GWT stuff
61 vmassol - (10:21): and is it documented on dev.xwiki.org in the testing section?
62 vmassol - (10:22): something like: we use GWTTestCase for unit testing and this is how to use it
63 vmassol - (10:22): and we use selenium tests for functional tests, etc
64 vmassol - (10:22): (is that our current strategy?)
65 vmassol - (10:23): I think http://dev.xwiki.org/xwiki/bin/view/Community/Testing lacks a bit of info re gwt testing
66 mflorea - (10:23): it's not documented, only me and Anca have written GWT unit tests so far I think. The "rule" is, as I said, to write plain unit tests for code that is not UI related and that is not browser specific and to write GWTTestCase for the rest. Currently, in our gwt module we have both types of tests
67 nickless joined #xwiki at 10:25
68 mflorea - (10:26): I'll find the time to add this info to Community.Testing page
69 vmassol - (10:28): ok gr8
70 florinciu joined #xwiki at 10:30
71 tmortagne - (10:33): does someone knows a way to access panel document from the panel itself when it's rendered in the context of a document ?
72 tmortagne - (10:33): does not seems to exists any context variable with the panel
73 vmassol - (10:34): don't we have a $panelDoc or somethinf?
74 vmassol - (10:34): it would be defined in macros.vm
75 vmassol - (10:34): (if it exists)
76 tmortagne - (10:34): i already looked and nothing is set in displayPanel
77 tmortagne - (10:34): displaypanel
78 tmortagne - (10:35): but in case i'm asking in case i did not seen something
79 vmassol - (10:35): tmortagne: I see this:
80 vmassol - (10:35): #if ($paneldoc && $paneldoc != "")
81 vmassol - (10:35): so it must be set somewhere I guess
82 vmassol - (10:35): checking
83 tmortagne - (10:36): it's a local variable of the macro
84 tmortagne - (10:36): a velocity variable
85 tmortagne - (10:36): i don't know if you can access this variable in the panel itself
86 vmassol - (10:36): #set ($paneldoc = $xwiki.getDocument($name))
87 vmassol - (10:36): can you try?
88 tmortagne - (10:36): but anyway i want to access this information from java
89 vmassol - (10:36): ah
90 tmortagne - (10:37): basically i would need some "realcurrentdoc" context entry
91 Denis - (10:38): tmortagne: I have used vcontext.get('panel') or $panel for that, but this is clearly a hack IMO
92 Denis - (10:39): you should also default to the current doc for the case you are on the panel doc, and no $panel is defined when you display the panel there
93 tmortagne - (10:41): i'm not really writing something in a panel, my use case is to know the real document of the source when i'm in getRenderedContent
94 tmortagne - (10:41): (the one that take the source as string)
95 Denis - (10:42): than you ask to wrong question, and my feeling is that there is no answer currently
96 Denis - (10:42): there is a serious issue in the way templates, panels, and other interface element are displayed...
97 tmortagne - (10:42): i knows there is nothing to know the real current document
98 tmortagne - (10:43): i just trying to find a way to resolve it for now
99 Denis - (10:43): good luck !
100 tmortagne - (10:43): yes...
101 CalebJamesDeLisl - (10:51): vmassol: Any comment on my secure filesystem access proposal? I think it is relevant to your work on components.
102 vmassol - (10:54): CalebJamesDeLisl: sorry otp right now and no I haven't thought enough about it. I started thinking about it but I don't have enough context to answer
103 CalebJamesDeLisl - (10:55): Ok
104 sdumitriu joined #xwiki at 10:58
105 sdumitriu - (11:05): jvelociter: Where's the noscript macro?
106 jvelociter - (11:05): not uploaded right now, I had issues with internet yday
107 jvelociter - (11:05): but I will do that now
108 CalebJamesDeLisl - (11:10): I was saying earlier that I feel like the current security methods are constraining the attempts to fix bugs. I seem to recall you sdumitriu were an advocate of the way things are currently done, maybe you can speak to my concerns?
109 mariusbutuc joined #xwiki at 11:10
110 jvelociter - (11:11): sdumitriu: it's there now:)
111 tmortagne - (11:14): jvelociter: we should probably add a remove method in org.xwiki.rendering.block.Block
112 jvelociter - (11:14): tmortagne: agreed, I looked for it initially ;)
113 jvelociter - (11:15): (forgot to report it after the training session)
114 tmortagne - (11:15): just one thing, this macro should be a java macro IMO
115 tmortagne - (11:15): you would not need to render it back to xwiki/2.0 syntax
116 tmortagne - (11:17): also your macro support only xwiki/2.0 syntax
117 tmortagne - (11:17): in java it would support any syntax
118 jvelociter - (11:17): tmortagne: yes it would be better. Originally it was an illustration of wiki macros and rendering APIs
119 jvelociter - (11:17): it's not really meant to be used as is
120 tmortagne - (11:18): i think we should have a way to return java Block object in wiki macro
121 tmortagne - (11:19): it's not difficult, we just need something like xcontext.macro.return(blocks)
122 tmortagne - (11:19): it would havoid having to render blocks to reparse it if you already have them
123 tmortagne - (11:20): creating an issue for it
124 jvelociter - (11:22): ok
125 tmortagne - (11:25): ( http://jira.xwiki.org/jira/browse/XWIKI-5124 )
126 mflorea left at 11:26 (Quit: Leaving.
127 jvelociter - (11:46): interesting post on facebook JS perf http://ajaxian.com/archives/facebook-javascript-jsconf
128 bougie - (11:54): tmortagne: hello
129 bougie - (11:54): my auth is working :)
130 tmortagne - (11:54): bougie: hi
131 tmortagne - (11:54): ha great :)
132 plunden1 joined #xwiki at 11:55
133 CalebJamesDeLisl - (11:56): We don't have as much js as facebook, I think our main problem is it's spread over a lot of files. Unifying them would pick things up dramatically but I don't want to develop that until the new action model is in place.
134 CalebJamesDeLisl - (11:58): A concept that I find interesting is sandboxing user script so we don't have to filter out all possible XSS.
135 CalebJamesDeLisl - (12:01): The most simplistic form would be window.xmlHttpRequest = undefined; and any code which ran after that would not be able to make ajax requests.
136 sdumitriu - (12:04): Not quite
137 sdumitriu - (12:04): In IE, which is the most troublesome, AJAX is done with an activeX object
138 sdumitriu - (12:05): And I doubt you can get rid of them that easily
139 sdumitriu - (12:05): Plus, you would prevent ALL code from doing Ajax, since there is only one global scope
140 CalebJamesDeLisl - (12:06): Well I would want the code which needs xmlHttpRequest to get references and store them in closures where they are safe first.
141 CalebJamesDeLisl - (12:07): But the IE issue is a breaker.
142 CalebJamesDeLisl - (12:08): There is also Caja rewriter but I haven't looked into it much
143 vmassol - (12:12): guys the jira service is going to be restarted by the infra team to apply a security patch
144 jvelociter - (12:13): (1:00 pm Paris time)
145 CalebJamesDeLisl - (12:14): vmassol: Do you have any specific questions about the secure filesystem access proposal?
146 vmassol - (12:15): not right now caleb, I don't want to be a blocking point. I won't have time to think about before 2-3 weeks from now
147 vmassol - (12:15): (one week of holiday + one week business travel + one week preparation of a training + my stuff I work on,e tc)
148 vmassol - (12:15): I think you should make some more global architecture proposal
149 CalebJamesDeLisl - (12:16): Ok. Maybe someone else can look at it? I would like to have at lease one community member review it before I start work.
150 vmassol - (12:16): CalebJamesDeLisl: you're workong on how many things at once? :)
151 vmassol - (12:16): actions, invitation, security, perfs, etc ;)
152 vmassol - (12:17): on my side
153 vmassol - (12:17): I need a vision of where we want to go in the new architecture re general authentication/authorization too
154 vmassol - (12:17): before I can answer some specific question in one specific area
155 vmassol - (12:18): sorry got to go again (was in meeting and now need to go for lunch...)
156 CalebJamesDeLisl - (12:18): Ok. actions and js performance seem to be stalled at the moment, everything else is waiting on the list.
157 florinciu left at 12:28 (Read error: Connection reset by peer
158 florinciu joined #xwiki at 12:34
159 CalebJamesDeLisl - (12:35): Hmm, apparently I never send the mail asking how to add the email inviter to the sandbox. Just sent.
160 mflorea joined #xwiki at 12:37
161 nickless left at 13:02 (Ping timeout: 245 seconds
162 nickless joined #xwiki at 13:27
163 jvdrean joined #xwiki at 13:41
164 gvallarelli - (13:47): so the 16 proposal win
165 sdumitriu - (13:47): Yes
166 sdumitriu - (13:47): But it still needs to be changed
167 sdumitriu - (13:48): So, do you know what your chances are to get a slot?
168 gvallarelli - (13:49): I don't know anything... Except that proposal sent to nescent are 30 and there are a lot of good ones
169 arkub joined #xwiki at 13:50
170 gvallarelli - (13:50): maybe in this week I'll know something, maybe... But at this point I don't take care too much, I'll wait for the final results
171 sdumitriu - (13:50): Yes, best thing is not to worry too much
172 sdumitriu - (13:51): The outcome will be the same wether you worry or relax
173 gvallarelli - (13:51): yep
174 gvallarelli - (13:52): I agree with the decision to improve 16 proposal, and I voted for 16 in the first round but after that I've seen the second iteration of pencils (4 proposal) I like it more than 16
175 mariusbutuc left at 13:57 (*.net *.split
176 xipe left at 13:57 (*.net *.split
177 mariusbutuc joined #xwiki at 14:03
178 xipe joined #xwiki at 14:03
179 plunden left at 14:17 (Ping timeout: 276 seconds
180 florinciu left at 14:30 (Read error: Connection reset by peer
181 florinciu joined #xwiki at 14:31
182 arkub left at 14:34 (Ping timeout: 258 seconds
183 silviar left #xwiki at 14:41
184 CalebJamesDeLisl - (14:50): Is the standard for translation keys supposed to be camel case or not?
185 glerouge - (14:50): not necessarily
186 sdumitriu - (14:51): Caleb: YES, YES!
187 sdumitriu - (14:51): Don't listen to glerouge
188 CalebJamesDeLisl - (14:51): Ok, I was wondering if we were going to camel case or from it :)
189 sdumitriu - (14:52): To
190 glerouge - (14:52): I thought it was some.translation.key=Some translation value
191 glerouge - (14:52): where's CamelCase in that?
192 CalebJamesDeLisl - (14:53): some.thisVeryCoolTranslation.key=Translation...
193 glerouge - (14:53): for a real one? ;)
194 CalebJamesDeLisl - (14:53): xe.blog.manageCategories.comment.updatedParent=Updated category parent
195 glerouge - (14:54): I'm going to go bury myself and I'll be back
196 CalebJamesDeLisl - (14:54): :)
197 mariusbutuc left at 14:55 (Quit: Leaving.
198 evalica left at 15:52 (Read error: Connection reset by peer
199 Enygma` left at 15:52 (Quit: Leaving.
200 arkub joined #xwiki at 16:16
201 arkub left at 16:17 (Remote host closed the connection
202 arkub joined #xwiki at 16:24
203 florinciu left at 16:30 (Read error: Connection reset by peer
204 florinciu joined #xwiki at 16:32
205 nickless left at 16:36 (Ping timeout: 265 seconds
206 CalebJamesDeLisl - (16:53): Any suggestion for what translation keys should be named for the liveValidation translations?
207 CalebJamesDeLisl - (16:54): platform.js.validation.okMessage=Ok
208 CalebJamesDeLisl - (16:54): ?
209 sdumitriu - (16:56): Caleb, can you make a patch?
210 sdumitriu - (16:57): And bug me until I review it?
211 sdumitriu - (16:57): platform, ok
212 sdumitriu - (16:57): I'm not sure about js
213 sdumitriu - (16:57): Better not
214 CalebJamesDeLisl - (16:57): A patch for validation translations?
215 sdumitriu - (16:57): validation, ok
216 vmassol - (16:57): sdumitriu: we have a rule defined for translation keys? I remember discussing it but I don't see any rule defined on dev.xwiki.org
217 vmassol - (16:58): (and i don't recall details of that discussion or whether we reached a conclusion)
218 vmassol - (16:58): we do have a rule for naming config properties though
219 sdumitriu - (16:58): We have some rules, but the rules aren't very precise
220 CalebJamesDeLisl - (16:58): The other day you referenced an email thread but it was for configuration files.
221 sdumitriu - (16:58): They just say that it should be application.part.key
222 sdumitriu - (16:59): From there, it's common sense
223 sdumitriu - (16:59): Like any naming rule, there are just some suggestions that leave plenty of room for variations
224 gvallarelli left at 16:59 (Ping timeout: 240 seconds
225 CalebJamesDeLisl - (17:00): and variations there are ;)
226 plunden1 left #xwiki at 17:00
227 CalebJamesDeLisl - (17:01): One possibility to fix the old translations would be $msg.get2 gets using a new naming method and $msg.get uses the old (but I am involved in enough already.)
228 CalebJamesDeLisl - (17:02): So. platform.validation.okMessage=Ok?
229 sdumitriu - (17:02): Looks good so far
230 sdumitriu - (17:02): maibe validMessage?
231 sdumitriu - (17:02): ok is not very proper...
232 CalebJamesDeLisl - (17:03): It's going to spend some time in the sandbox as a language pack first anyway.
233 sdumitriu - (17:03): Or, depending on how many messages there are, maybe:
234 sdumitriu - (17:03): platform.validation.messages.ok
235 CalebJamesDeLisl - (17:04): I only have ok, fieldMandatory and invalidEmail at the moment.
236 vmassol - (17:04): naming stuff is the hardest part of programming ;)
237 sdumitriu - (17:05): vmassol: It's easy, just use i and j
238 sdumitriu - (17:05): :)
239 CalebJamesDeLisl - (17:05): You would think coming up with names was easy looking at the translations document (or any api for that matter)
240 sdumitriu - (17:08): The existng translations are not good inspiration
241 sdumitriu - (17:08): There are probably more than 5 different naming strategies in there
242 CalebJamesDeLisl - (17:09): Yea I think there is a definite need for having a way to change translation keys without breaking old code.
243 vmassol - (17:15): that's not really possible caleb, by definition :)
244 tmortagne - (17:16): well we could maintain some kind of retro compatibility mapping, oldkey=newkey
245 vmassol - (17:16): the point of descriptive names in key names is to make it easy to use and meaningful, if you replace this with unique ids then you loose that feature
246 CalebJamesDeLisl - (17:16): What tmortagne said.
247 vmassol - (17:16): yes retro is possible, ie aliases
248 tmortagne - (17:16): yep aliases
249 tmortagne - (17:16): aliases could be useful for other use cases
250 vmassol - (17:17): yes we talked about it tmortagne
251 vmassol - (17:17): btw I think this is supported already for our configuration files AFAIR
252 vmassol - (17:17): (it comes from commons-configuration)
253 tmortagne - (17:17): we cool look at what commons-configuration do then
254 tmortagne - (17:18): s/cool/could/
255 vmassol - (17:18): let me find the link
256 vmassol - (17:18): it transforms them into variables AFAIR
257 vmassol - (17:18): something like:
258 vmassol - (17:18): my.key1 = value1
259 vmassol - (17:18): my.key2 = ${my.key1}
260 vmassol - (17:18): let me find it
261 vmassol - (17:19): it' called variable interpolation
262 vmassol - (17:19): http://commons.apache.org/configuration/userguide/howto_basicfeatures.html#Variable_Interpolation
263 vmassol - (17:20): so the good news is that we can use this retro compat feature for our new config files :)
264 tmortagne - (17:20): "application.title = ${application.name} ${application.version}", that's nice, pretty much what is suggested some time ago for l10n when talking about rendering l10n
265 tmortagne - (17:21): if there is a reusable l10n value parser we should use it for l10n, would be more consistent
266 tmortagne - (17:21): that way it would fit my need for rendering
267 vmassol - (17:22): nice new maven refactoring in IDEA: http://bit.ly/9v26zt
268 vmassol - (17:23): I don't know any off the top of my head
269 vmassol - (17:23): well
270 vmassol - (17:23): EL is one
271 vmassol - (17:23): velocity is another
272 vmassol - (17:24): (el: http://java.sun.com/javaee/5/docs/api/javax/el/package-summary.html)
273 vmassol - (17:25): and a lot of others
274 vmassol - (17:27): http://stackoverflow.com/questions/1412132/use-property-in-a-properties-file
275 CalebJamesDeLisl - (17:27): Is the message getter in rendering documented? I couldn't find it.
276 vmassol - (17:28): so we could use commons configuration for reading translation property files too
277 vmassol - (17:29): ie use xwiki-configuration
278 CalebJamesDeLisl - (17:30): Hmm, looks like code reduction, and it's code which needs filesystem access.
279 vmassol - (17:33): (would need some sort of bridge between ResourceBundle and commons configuration)
280 vmassol - (17:35): reading http://n4.nabble.com/Commons-Configuration-for-i18n-td999273.html
281 mflorea left at 17:36 (Quit: Leaving.
282 lucaa left at 17:37 (Quit: Leaving.
283 nickless joined #xwiki at 17:39
284 nickless left at 18:01 (Ping timeout: 276 seconds
285 florinciu left at 18:30 (Read error: Connection reset by peer
286 bougie - (18:51): tmortagne: if i give you my xwiki.cfg en my ldap schema, can you add my content to xwiki ldap page ?
287 bougie - (18:51): s/en/and
288 tmortagne - (18:52): bougie: best is to explain what you had to do to make auth work with your LDAP server (you just need to have an account on xwiki.org)
289 tmortagne - (18:53): you have all right to modify the page on xwiki.org
290 jvdrean left at 19:01 (Quit: Leaving.
291 KermitTheFragger left at 19:09 (Quit: Leaving
292 arkub left at 19:13 (Ping timeout: 258 seconds
293 bougie - (19:18): sorry for my english :/
294 glerouge left at 19:19 (Quit: Leaving.
295 tmortagne - (19:24): bougie: i doubt it's working with empty xwiki.authentication.ldap.bind_DN and xwiki.authentication.ldap.bind_pass
296 bougie - (19:24): when it's empty, it's an anonymous connexion
297 bougie - (19:25): and with opends, you can list and read some attributs
298 tmortagne - (19:25): ha ok ineed i forgot about that since i always configure LDAP for LDAP server that does not alllow anonymous access :)
299 tmortagne - (19:26): you should probably say it
300 tmortagne - (19:26): describe a little more what it's doing
301 tmortagne - (19:26): also you should remove so default values:
302 tmortagne - (19:28): xwiki.authentication.ldap.validate_password=0
303 tmortagne - (19:28): xwiki.authentication.ldap.UID_attr=cn
304 tmortagne - (19:28): xwiki.authentication.ldap.password_field (only used with xwiki.authentication.ldap.validate_password=1)
305 tmortagne - (19:28): xwiki.authentication.ldap.update_user=1
306 tmortagne - (19:28): xwiki.authentication.ldap.groupcache_expiration=3600xwiki.authentication.ldap.mode_group_sync=always xwiki.authentication.ldap.trylocal=1
307 tmortagne - (19:28): xwiki.authentication.ldap.groupcache_expiration=3600
308 tmortagne - (19:28): xwiki.authentication.ldap.mode_group_sync=always
309 tmortagne - (19:28): xwiki.authentication.ldap.trylocal=1
310 tmortagne - (19:28): to make more clear what is specific to ApacheDS
311 tmortagne - (19:28): OpenDS sorry
312 tmortagne - (19:29): like it's done for "Apple Open Directory Server"
313 tmortagne - (19:39): bougie: great :)
314 tmortagne - (19:39): is uppercase I in "DIrectory" on purpose ? :)
315 tmortagne - (19:40): looking at the source remain me i need to convert this page to xwiki/2.0 syntax
316 tmortagne - (19:47): bougie: you have two different configurations for xwiki.authentication.ldap.bind_DN
317 tmortagne - (19:47): by bad
318 tmortagne - (19:47): missread
319 tmortagne - (19:48): bougie: btw as far as i can see groupOfNames is part of the default group classes, it does not work without it ?
320 tmortagne left at 20:00 (Quit: Leaving.
321 anamarias joined #xwiki at 20:14
322 anamarias left at 20:14 (Client Quit
323 anamarias joined #xwiki at 20:15
324 florinciu joined #xwiki at 20:18
325 kibahop joined #xwiki at 20:22
326 kibahop left #xwiki at 20:23
327 anamarias left at 20:53 (Quit: anamarias
328 florinciu left at 21:08 (Read error: Connection reset by peer
329 jvdrean joined #xwiki at 21:11
330 florinciu joined #xwiki at 21:37
331 anamarias joined #xwiki at 21:42
332 anamarias left at 21:45 (Client Quit
333 anamarias joined #xwiki at 21:48
334 anamarias left #xwiki at 21:50
335 Denis - (22:01): sdumitriu: would you want me to change the link into a button ?
336 sdumitriu - (22:02): Well, we're trying to keep the wiki accessible
337 sdumitriu - (22:02): This means that everything must work without javascript
338 sdumitriu - (22:02): So, the usual way to do it is:
339 sdumitriu - (22:02): - keep the href something that would work
340 Denis - (22:02): sdumitriu: agreed, but this .vm is already always in a lightbox
341 sdumitriu - (22:02): - add a listener from javascript
342 Denis - (22:03): it is not meant to be used outside of it, and would not work
343 sdumitriu - (22:03): Are you sure?
344 Denis - (22:03): <span class="buttonwrapper"><input class="button" type="submit" name="formactionsave" value="$msg.get("save")" onclick=" window.lb.l
345 Denis - (22:03): <span class="buttonwrapper"><input class="button" type="submit" name="formactioncancel" value="$msg.get("cancel")" onclick=" window.
346 Denis - (22:04): oups
347 Denis - (22:04): <span class="buttonwrapper"><input class="button" type="submit" name="formactionsave" value="$msg.get("save")" onclick=" window.lb.lbSaveForm();"/></span>
348 Denis - (22:04): <span class="buttonwrapper"><input class="button" type="submit" name="formactioncancel" value="$msg.get("cancel")" onclick=" window.lb.lbHide(); window.lb.lbClearData(); return false;"/></span>
349 Denis - (22:04): here is the form submits
350 Denis - (22:05): so in a lightbox or useless
351 Denis - (22:05): this is why I have done so
352 Denis - (22:05): we could refactor this UI, but this is not my initial goal
353 Denis - (22:06): just want to avoid the lightbox being replaced by a fullscreen document when you pass over the lock
354 sdumitriu - (22:06): K
355 sdumitriu - (22:07): Then you could leave it as it is for the moment
356 sdumitriu - (22:07): And in the future we'll have to redo this whole part
357 Denis - (22:09): sdumitriu: by the way, why have you only apply my patch for http://jira.xwiki.org/jira/browse/XWIKI-4378 to 2.3 and not 2.2, I would like to fixe XWIKI-5004 in 2.2 has well, since this is not risky (I use it myself in production), and this is completly broken
358 sdumitriu - (22:10): Well, 2.2 is an old branch, and usually only critical bugfixes should be in
359 sdumitriu - (22:10): If you need it, you could apply it, though
360 Denis - (22:12): ok, thanks
361 nickless joined #xwiki at 22:50
362 plunden joined #xwiki at 22:53
363 florinciu left at 23:05 (Quit: Leaving.
364 vmassol left at 23:08 (Quit: Leaving.
365 florinciu joined #xwiki at 23:10
366 Denis left at 23:27 (Quit: Leaving.
367 jvdrean left at 23:50 (Quit: Leaving.
368 florinciu left at 23:59 (Read error: Connection reset by peer

Get Connected