IRC Archive for channel #xwiki
Last modified by Vincent Massol on 2012/10/18 19:11
jvdrean joined #xwiki at 00:13
vmassol - (00:15): jvelociter: hi, I don't understand the need for your noscript macro
jvdrean left #xwiki at 00:15
vmassol - (00:15): what's the difference with {{{…}}} for example?
vmassol - (00:16): ok I think I see
vmassol - (00:16): it executes everything except script macros
vmassol - (00:17): I'm still curious to understand why a combination of {{{…}}} and standard wiki syntax wouldn't work
vmassol - (00:17): maybe you're doing some {{include}} and don't fully control its content
vmassol - (00:18): or something like this
vmassol - (00:18): :)
vmassol left at 00:34 (Quit: Leaving.
Denis left at 07:04 (Ping timeout: 276 seconds
Denis joined #xwiki at 07:10
mflorea joined #xwiki at 07:23
Denis1 joined #xwiki at 07:39
Denis left at 07:41 (Ping timeout: 276 seconds
vmassol joined #xwiki at 07:45
kibahop joined #xwiki at 07:48
kibahop left #xwiki at 08:22
npm left at 08:41 (Quit: Leaving.
npm joined #xwiki at 08:43
Denis1 is now known as Denis ([email protected]
tmortagne joined #xwiki at 09:22
Enygma` joined #xwiki at 09:22
lucaa left at 09:27 (Quit: Leaving.
evalica joined #xwiki at 09:29
silviar joined #xwiki at 09:30
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)
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)
CalebJamesDeLisl - (09:38): jvelociter: That's cool, do you handle possibilities like onclick=?
jvelociter - (09:39): CalebJamesDeLisl: actually it's no JSR223 {{script}} :)
jvelociter - (09:39): but we could forbid HTML easily, too
CalebJamesDeLisl - (09:39): Ahh yes, I forgot.
jvelociter - (09:39): forbidding just <script> might be a bit trickier
vmassol - (09:41): jvelociter: ok thanks. That's the only use case I could find too.
CalebJamesDeLisl - (09:41): Ahh, there's more than just <script> :( http://jira.xwiki.org/jira/browse/XWIKI-4874
jvelociter - (09:41): vmassol: there is another one though
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 :)
jvelociter - (09:42): (but that's not good practice one could argue)
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.
vmassol - (09:44): external mixed input is the use case indeed
vmassol - (09:44): CalebJamesDeLisl: yes we need to revisit it
jvelociter - (09:45): xipe could not agree more I believe :)
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.
jvelociter - (09:46): well at some points the commits give up the secret anyway
CalebJamesDeLisl - (09:46): In some cases we can rewrite things and hide it, but sometimes we just can't.
CalebJamesDeLisl - (09:47): Also I think we need to synchronize with the Hibernate folks since 4755 is really their issue.
tmortagne left at 09:55 (Remote host closed the connection
tmortagne joined #xwiki at 09:56
KermitTheFragger joined #xwiki at 10:00
lucaa joined #xwiki at 10:03
glerouge joined #xwiki at 10:05
vmassol - (10:05): mflorea: haven't read it but maybe this is useful to us: http://www.infoq.com/articles/gwt_unit_testing ?
vmassol - (10:06): (or maybe not)
gvallarelli joined #xwiki at 10:16
gvallarelli - (10:16): Hi XWikiers!
CalebJamesDeLisl - (10:17): Hi gvallarelli
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
vmassol - (10:21): do we have a strategy right now?
vmassol - (10:21): for testing GWT stuff
vmassol - (10:21): and is it documented on dev.xwiki.org in the testing section?
vmassol - (10:22): something like: we use GWTTestCase for unit testing and this is how to use it
vmassol - (10:22): and we use selenium tests for functional tests, etc
vmassol - (10:22): (is that our current strategy?)
vmassol - (10:23): I think http://dev.xwiki.org/xwiki/bin/view/Community/Testing lacks a bit of info re gwt testing
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
nickless joined #xwiki at 10:25
mflorea - (10:26): I'll find the time to add this info to Community.Testing page
vmassol - (10:28): ok gr8
florinciu joined #xwiki at 10:30
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 ?
tmortagne - (10:33): does not seems to exists any context variable with the panel
vmassol - (10:34): don't we have a $panelDoc or somethinf?
vmassol - (10:34): it would be defined in macros.vm
vmassol - (10:34): (if it exists)
tmortagne - (10:34): i already looked and nothing is set in displayPanel
tmortagne - (10:34): displaypanel
tmortagne - (10:35): but in case i'm asking in case i did not seen something
vmassol - (10:35): tmortagne: I see this:
vmassol - (10:35): #if ($paneldoc && $paneldoc != "")
vmassol - (10:35): so it must be set somewhere I guess
vmassol - (10:35): checking
tmortagne - (10:36): it's a local variable of the macro
tmortagne - (10:36): a velocity variable
tmortagne - (10:36): i don't know if you can access this variable in the panel itself
vmassol - (10:36): #set ($paneldoc = $xwiki.getDocument($name))
vmassol - (10:36): can you try?
tmortagne - (10:36): but anyway i want to access this information from java
vmassol - (10:36): ah
tmortagne - (10:37): basically i would need some "realcurrentdoc" context entry
Denis - (10:38): tmortagne: I have used vcontext.get('panel') or $panel for that, but this is clearly a hack IMO
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
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
tmortagne - (10:41): (the one that take the source as string)
Denis - (10:42): than you ask to wrong question, and my feeling is that there is no answer currently
Denis - (10:42): there is a serious issue in the way templates, panels, and other interface element are displayed...
tmortagne - (10:42): i knows there is nothing to know the real current document
tmortagne - (10:43): i just trying to find a way to resolve it for now
Denis - (10:43): good luck !
tmortagne - (10:43): yes...
CalebJamesDeLisl - (10:51): vmassol: Any comment on my secure filesystem access proposal? I think it is relevant to your work on components.
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
CalebJamesDeLisl - (10:55): Ok
sdumitriu joined #xwiki at 10:58
sdumitriu - (11:05): jvelociter: Where's the noscript macro?
jvelociter - (11:05): not uploaded right now, I had issues with internet yday
jvelociter - (11:05): but I will do that now
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?
mariusbutuc joined #xwiki at 11:10
jvelociter - (11:11): sdumitriu: it's there now:)
tmortagne - (11:14): jvelociter: we should probably add a remove method in org.xwiki.rendering.block.Block
jvelociter - (11:14): tmortagne: agreed, I looked for it initially ;)
jvelociter - (11:15): (forgot to report it after the training session)
tmortagne - (11:15): just one thing, this macro should be a java macro IMO
tmortagne - (11:15): you would not need to render it back to xwiki/2.0 syntax
tmortagne - (11:17): also your macro support only xwiki/2.0 syntax
tmortagne - (11:17): in java it would support any syntax
jvelociter - (11:17): tmortagne: yes it would be better. Originally it was an illustration of wiki macros and rendering APIs
jvelociter - (11:17): it's not really meant to be used as is
tmortagne - (11:18): i think we should have a way to return java Block object in wiki macro
tmortagne - (11:19): it's not difficult, we just need something like xcontext.macro.return(blocks)
tmortagne - (11:19): it would havoid having to render blocks to reparse it if you already have them
tmortagne - (11:20): creating an issue for it
jvelociter - (11:22): ok
tmortagne - (11:25): ( http://jira.xwiki.org/jira/browse/XWIKI-5124 )
mflorea left at 11:26 (Quit: Leaving.
jvelociter - (11:46): interesting post on facebook JS perf http://ajaxian.com/archives/facebook-javascript-jsconf
bougie - (11:54): tmortagne: hello
bougie - (11:54): my auth is working :)
tmortagne - (11:54): bougie: hi
tmortagne - (11:54): ha great :)
plunden1 joined #xwiki at 11:55
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.
CalebJamesDeLisl - (11:58): A concept that I find interesting is sandboxing user script so we don't have to filter out all possible XSS.
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.
sdumitriu - (12:04): Not quite
sdumitriu - (12:04): In IE, which is the most troublesome, AJAX is done with an activeX object
sdumitriu - (12:05): And I doubt you can get rid of them that easily
sdumitriu - (12:05): Plus, you would prevent ALL code from doing Ajax, since there is only one global scope
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.
CalebJamesDeLisl - (12:07): But the IE issue is a breaker.
CalebJamesDeLisl - (12:08): There is also Caja rewriter but I haven't looked into it much
vmassol - (12:12): guys the jira service is going to be restarted by the infra team to apply a security patch
jvelociter - (12:13): (1:00 pm Paris time)
CalebJamesDeLisl - (12:14): vmassol: Do you have any specific questions about the secure filesystem access proposal?
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
vmassol - (12:15): (one week of holiday + one week business travel + one week preparation of a training + my stuff I work on,e tc)
vmassol - (12:15): I think you should make some more global architecture proposal
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.
vmassol - (12:16): CalebJamesDeLisl: you're workong on how many things at once? :)
vmassol - (12:16): actions, invitation, security, perfs, etc ;)
vmassol - (12:17): on my side
vmassol - (12:17): I need a vision of where we want to go in the new architecture re general authentication/authorization too
vmassol - (12:17): before I can answer some specific question in one specific area
vmassol - (12:18): sorry got to go again (was in meeting and now need to go for lunch...)
CalebJamesDeLisl - (12:18): Ok. actions and js performance seem to be stalled at the moment, everything else is waiting on the list.
florinciu left at 12:28 (Read error: Connection reset by peer
florinciu joined #xwiki at 12:34
CalebJamesDeLisl - (12:35): Hmm, apparently I never send the mail asking how to add the email inviter to the sandbox. Just sent.
mflorea joined #xwiki at 12:37
nickless left at 13:02 (Ping timeout: 245 seconds
nickless joined #xwiki at 13:27
jvdrean joined #xwiki at 13:41
gvallarelli - (13:47): so the 16 proposal win
sdumitriu - (13:47): Yes
sdumitriu - (13:47): But it still needs to be changed
sdumitriu - (13:48): So, do you know what your chances are to get a slot?
gvallarelli - (13:49): I don't know anything... Except that proposal sent to nescent are 30 and there are a lot of good ones
arkub joined #xwiki at 13:50
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
sdumitriu - (13:50): Yes, best thing is not to worry too much
sdumitriu - (13:51): The outcome will be the same wether you worry or relax
gvallarelli - (13:51): yep
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
mariusbutuc left at 13:57 (*.net *.split
xipe left at 13:57 (*.net *.split
mariusbutuc joined #xwiki at 14:03
xipe joined #xwiki at 14:03
plunden left at 14:17 (Ping timeout: 276 seconds
florinciu left at 14:30 (Read error: Connection reset by peer
florinciu joined #xwiki at 14:31
arkub left at 14:34 (Ping timeout: 258 seconds
silviar left #xwiki at 14:41
CalebJamesDeLisl - (14:50): Is the standard for translation keys supposed to be camel case or not?
glerouge - (14:50): not necessarily
sdumitriu - (14:51): Caleb: YES, YES!
sdumitriu - (14:51): Don't listen to glerouge
CalebJamesDeLisl - (14:51): Ok, I was wondering if we were going to camel case or from it :)
sdumitriu - (14:52): To
glerouge - (14:52): I thought it was some.translation.key=Some translation value
glerouge - (14:52): where's CamelCase in that?
CalebJamesDeLisl - (14:53): some.thisVeryCoolTranslation.key=Translation...
glerouge - (14:53): for a real one? ;)
CalebJamesDeLisl - (14:53): xe.blog.manageCategories.comment.updatedParent=Updated category parent
glerouge - (14:54): I'm going to go bury myself and I'll be back
CalebJamesDeLisl - (14:54): :)
mariusbutuc left at 14:55 (Quit: Leaving.
evalica left at 15:52 (Read error: Connection reset by peer
Enygma` left at 15:52 (Quit: Leaving.
arkub joined #xwiki at 16:16
arkub left at 16:17 (Remote host closed the connection
arkub joined #xwiki at 16:24
florinciu left at 16:30 (Read error: Connection reset by peer
florinciu joined #xwiki at 16:32
nickless left at 16:36 (Ping timeout: 265 seconds
CalebJamesDeLisl - (16:53): Any suggestion for what translation keys should be named for the liveValidation translations?
CalebJamesDeLisl - (16:54): platform.js.validation.okMessage=Ok
CalebJamesDeLisl - (16:54): ?
sdumitriu - (16:56): Caleb, can you make a patch?
sdumitriu - (16:57): And bug me until I review it?
sdumitriu - (16:57): platform, ok
sdumitriu - (16:57): I'm not sure about js
sdumitriu - (16:57): Better not
CalebJamesDeLisl - (16:57): A patch for validation translations?
sdumitriu - (16:57): validation, ok
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
vmassol - (16:58): (and i don't recall details of that discussion or whether we reached a conclusion)
vmassol - (16:58): we do have a rule for naming config properties though
sdumitriu - (16:58): We have some rules, but the rules aren't very precise
CalebJamesDeLisl - (16:58): The other day you referenced an email thread but it was for configuration files.
sdumitriu - (16:58): They just say that it should be application.part.key
sdumitriu - (16:59): From there, it's common sense
sdumitriu - (16:59): Like any naming rule, there are just some suggestions that leave plenty of room for variations
gvallarelli left at 16:59 (Ping timeout: 240 seconds
CalebJamesDeLisl - (17:00): and variations there are ;)
plunden1 left #xwiki at 17:00
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.)
CalebJamesDeLisl - (17:02): So. platform.validation.okMessage=Ok?
sdumitriu - (17:02): Looks good so far
sdumitriu - (17:02): maibe validMessage?
sdumitriu - (17:02): ok is not very proper...
CalebJamesDeLisl - (17:03): It's going to spend some time in the sandbox as a language pack first anyway.
sdumitriu - (17:03): Or, depending on how many messages there are, maybe:
sdumitriu - (17:03): platform.validation.messages.ok
CalebJamesDeLisl - (17:04): I only have ok, fieldMandatory and invalidEmail at the moment.
vmassol - (17:04): naming stuff is the hardest part of programming ;)
sdumitriu - (17:05): vmassol: It's easy, just use i and j
sdumitriu - (17:05): :)
CalebJamesDeLisl - (17:05): You would think coming up with names was easy looking at the translations document (or any api for that matter)
sdumitriu - (17:08): The existng translations are not good inspiration
sdumitriu - (17:08): There are probably more than 5 different naming strategies in there
CalebJamesDeLisl - (17:09): Yea I think there is a definite need for having a way to change translation keys without breaking old code.
vmassol - (17:15): that's not really possible caleb, by definition :)
tmortagne - (17:16): well we could maintain some kind of retro compatibility mapping, oldkey=newkey
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
CalebJamesDeLisl - (17:16): What tmortagne said.
vmassol - (17:16): yes retro is possible, ie aliases
tmortagne - (17:16): yep aliases
tmortagne - (17:16): aliases could be useful for other use cases
vmassol - (17:17): yes we talked about it tmortagne
vmassol - (17:17): btw I think this is supported already for our configuration files AFAIR
vmassol - (17:17): (it comes from commons-configuration)
tmortagne - (17:17): we cool look at what commons-configuration do then
tmortagne - (17:18): s/cool/could/
vmassol - (17:18): let me find the link
vmassol - (17:18): it transforms them into variables AFAIR
vmassol - (17:18): something like:
vmassol - (17:18): my.key1 = value1
vmassol - (17:18): my.key2 = ${my.key1}
vmassol - (17:18): let me find it
vmassol - (17:19): it' called variable interpolation
vmassol - (17:19): http://commons.apache.org/configuration/userguide/howto_basicfeatures.html#Variable_Interpolation
vmassol - (17:20): so the good news is that we can use this retro compat feature for our new config files :)
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
tmortagne - (17:21): if there is a reusable l10n value parser we should use it for l10n, would be more consistent
tmortagne - (17:21): that way it would fit my need for rendering
vmassol - (17:22): nice new maven refactoring in IDEA: http://bit.ly/9v26zt
vmassol - (17:23): I don't know any off the top of my head
vmassol - (17:23): well
vmassol - (17:23): EL is one
vmassol - (17:23): velocity is another
vmassol - (17:24): (el: http://java.sun.com/javaee/5/docs/api/javax/el/package-summary.html)
vmassol - (17:25): and a lot of others
vmassol - (17:27): http://stackoverflow.com/questions/1412132/use-property-in-a-properties-file
CalebJamesDeLisl - (17:27): Is the message getter in rendering documented? I couldn't find it.
vmassol - (17:28): so we could use commons configuration for reading translation property files too
vmassol - (17:29): ie use xwiki-configuration
CalebJamesDeLisl - (17:30): Hmm, looks like code reduction, and it's code which needs filesystem access.
vmassol - (17:33): (would need some sort of bridge between ResourceBundle and commons configuration)
vmassol - (17:35): reading http://n4.nabble.com/Commons-Configuration-for-i18n-td999273.html
mflorea left at 17:36 (Quit: Leaving.
lucaa left at 17:37 (Quit: Leaving.
nickless joined #xwiki at 17:39
nickless left at 18:01 (Ping timeout: 276 seconds
florinciu left at 18:30 (Read error: Connection reset by peer
bougie - (18:51): tmortagne: if i give you my xwiki.cfg en my ldap schema, can you add my content to xwiki ldap page ?
bougie - (18:51): s/en/and
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)
tmortagne - (18:53): you have all right to modify the page on xwiki.org
jvdrean left at 19:01 (Quit: Leaving.
KermitTheFragger left at 19:09 (Quit: Leaving
arkub left at 19:13 (Ping timeout: 258 seconds
bougie - (19:18): sorry for my english :/
glerouge left at 19:19 (Quit: Leaving.
tmortagne - (19:24): bougie: i doubt it's working with empty xwiki.authentication.ldap.bind_DN and xwiki.authentication.ldap.bind_pass
bougie - (19:24): when it's empty, it's an anonymous connexion
bougie - (19:25): and with opends, you can list and read some attributs
tmortagne - (19:25): ha ok ineed i forgot about that since i always configure LDAP for LDAP server that does not alllow anonymous access :)
tmortagne - (19:26): you should probably say it
tmortagne - (19:26): describe a little more what it's doing
tmortagne - (19:26): also you should remove so default values:
tmortagne - (19:28): xwiki.authentication.ldap.validate_password=0
tmortagne - (19:28): xwiki.authentication.ldap.UID_attr=cn
tmortagne - (19:28): xwiki.authentication.ldap.password_field (only used with xwiki.authentication.ldap.validate_password=1)
tmortagne - (19:28): xwiki.authentication.ldap.update_user=1
tmortagne - (19:28): xwiki.authentication.ldap.groupcache_expiration=3600xwiki.authentication.ldap.mode_group_sync=always xwiki.authentication.ldap.trylocal=1
tmortagne - (19:28): xwiki.authentication.ldap.groupcache_expiration=3600
tmortagne - (19:28): xwiki.authentication.ldap.mode_group_sync=always
tmortagne - (19:28): xwiki.authentication.ldap.trylocal=1
tmortagne - (19:28): to make more clear what is specific to ApacheDS
tmortagne - (19:28): OpenDS sorry
tmortagne - (19:29): like it's done for "Apple Open Directory Server"
tmortagne - (19:39): bougie: great :)
tmortagne - (19:39): is uppercase I in "DIrectory" on purpose ? :)
tmortagne - (19:40): looking at the source remain me i need to convert this page to xwiki/2.0 syntax
tmortagne - (19:47): bougie: you have two different configurations for xwiki.authentication.ldap.bind_DN
tmortagne - (19:47): by bad
tmortagne - (19:47): missread
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 ?
tmortagne left at 20:00 (Quit: Leaving.
anamarias joined #xwiki at 20:14
anamarias left at 20:14 (Client Quit
anamarias joined #xwiki at 20:15
florinciu joined #xwiki at 20:18
kibahop joined #xwiki at 20:22
kibahop left #xwiki at 20:23
anamarias left at 20:53 (Quit: anamarias
florinciu left at 21:08 (Read error: Connection reset by peer
jvdrean joined #xwiki at 21:11
florinciu joined #xwiki at 21:37
anamarias joined #xwiki at 21:42
anamarias left at 21:45 (Client Quit
anamarias joined #xwiki at 21:48
anamarias left #xwiki at 21:50
Denis - (22:01): sdumitriu: would you want me to change the link into a button ?
sdumitriu - (22:02): Well, we're trying to keep the wiki accessible
sdumitriu - (22:02): This means that everything must work without javascript
sdumitriu - (22:02): So, the usual way to do it is:
sdumitriu - (22:02): - keep the href something that would work
Denis - (22:02): sdumitriu: agreed, but this .vm is already always in a lightbox
sdumitriu - (22:02): - add a listener from javascript
Denis - (22:03): it is not meant to be used outside of it, and would not work
sdumitriu - (22:03): Are you sure?
Denis - (22:03): <span class="buttonwrapper"><input class="button" type="submit" name="formactionsave" value="$msg.get("save")" onclick=" window.lb.l
Denis - (22:03): <span class="buttonwrapper"><input class="button" type="submit" name="formactioncancel" value="$msg.get("cancel")" onclick=" window.
Denis - (22:04): oups
Denis - (22:04): <span class="buttonwrapper"><input class="button" type="submit" name="formactionsave" value="$msg.get("save")" onclick=" window.lb.lbSaveForm();"/></span>
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>
Denis - (22:04): here is the form submits
Denis - (22:05): so in a lightbox or useless
Denis - (22:05): this is why I have done so
Denis - (22:05): we could refactor this UI, but this is not my initial goal
Denis - (22:06): just want to avoid the lightbox being replaced by a fullscreen document when you pass over the lock
sdumitriu - (22:06): K
sdumitriu - (22:07): Then you could leave it as it is for the moment
sdumitriu - (22:07): And in the future we'll have to redo this whole part
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
sdumitriu - (22:10): Well, 2.2 is an old branch, and usually only critical bugfixes should be in
sdumitriu - (22:10): If you need it, you could apply it, though
Denis - (22:12): ok, thanks
nickless joined #xwiki at 22:50
plunden joined #xwiki at 22:53
florinciu left at 23:05 (Quit: Leaving.
vmassol left at 23:08 (Quit: Leaving.
florinciu joined #xwiki at 23:10
Denis left at 23:27 (Quit: Leaving.
jvdrean left at 23:50 (Quit: Leaving.
florinciu left at 23:59 (Read error: Connection reset by peer
vmassol - (00:15): jvelociter: hi, I don't understand the need for your noscript macro
jvdrean left #xwiki at 00:15
vmassol - (00:15): what's the difference with {{{…}}} for example?
vmassol - (00:16): ok I think I see
vmassol - (00:16): it executes everything except script macros
vmassol - (00:17): I'm still curious to understand why a combination of {{{…}}} and standard wiki syntax wouldn't work
vmassol - (00:17): maybe you're doing some {{include}} and don't fully control its content
vmassol - (00:18): or something like this
vmassol - (00:18): :)
vmassol left at 00:34 (Quit: Leaving.
Denis left at 07:04 (Ping timeout: 276 seconds
Denis joined #xwiki at 07:10
mflorea joined #xwiki at 07:23
Denis1 joined #xwiki at 07:39
Denis left at 07:41 (Ping timeout: 276 seconds
vmassol joined #xwiki at 07:45
kibahop joined #xwiki at 07:48
kibahop left #xwiki at 08:22
npm left at 08:41 (Quit: Leaving.
npm joined #xwiki at 08:43
Denis1 is now known as Denis ([email protected]
tmortagne joined #xwiki at 09:22
Enygma` joined #xwiki at 09:22
lucaa left at 09:27 (Quit: Leaving.
evalica joined #xwiki at 09:29
silviar joined #xwiki at 09:30
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)
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)
CalebJamesDeLisl - (09:38): jvelociter: That's cool, do you handle possibilities like onclick=?
jvelociter - (09:39): CalebJamesDeLisl: actually it's no JSR223 {{script}} :)
jvelociter - (09:39): but we could forbid HTML easily, too
CalebJamesDeLisl - (09:39): Ahh yes, I forgot.
jvelociter - (09:39): forbidding just <script> might be a bit trickier
vmassol - (09:41): jvelociter: ok thanks. That's the only use case I could find too.
CalebJamesDeLisl - (09:41): Ahh, there's more than just <script> :( http://jira.xwiki.org/jira/browse/XWIKI-4874
jvelociter - (09:41): vmassol: there is another one though
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 :)
jvelociter - (09:42): (but that's not good practice one could argue)
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.
vmassol - (09:44): external mixed input is the use case indeed
vmassol - (09:44): CalebJamesDeLisl: yes we need to revisit it
jvelociter - (09:45): xipe could not agree more I believe :)
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.
jvelociter - (09:46): well at some points the commits give up the secret anyway
CalebJamesDeLisl - (09:46): In some cases we can rewrite things and hide it, but sometimes we just can't.
CalebJamesDeLisl - (09:47): Also I think we need to synchronize with the Hibernate folks since 4755 is really their issue.
tmortagne left at 09:55 (Remote host closed the connection
tmortagne joined #xwiki at 09:56
KermitTheFragger joined #xwiki at 10:00
lucaa joined #xwiki at 10:03
glerouge joined #xwiki at 10:05
vmassol - (10:05): mflorea: haven't read it but maybe this is useful to us: http://www.infoq.com/articles/gwt_unit_testing ?
vmassol - (10:06): (or maybe not)
gvallarelli joined #xwiki at 10:16
gvallarelli - (10:16): Hi XWikiers!
CalebJamesDeLisl - (10:17): Hi gvallarelli
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
vmassol - (10:21): do we have a strategy right now?
vmassol - (10:21): for testing GWT stuff
vmassol - (10:21): and is it documented on dev.xwiki.org in the testing section?
vmassol - (10:22): something like: we use GWTTestCase for unit testing and this is how to use it
vmassol - (10:22): and we use selenium tests for functional tests, etc
vmassol - (10:22): (is that our current strategy?)
vmassol - (10:23): I think http://dev.xwiki.org/xwiki/bin/view/Community/Testing lacks a bit of info re gwt testing
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
nickless joined #xwiki at 10:25
mflorea - (10:26): I'll find the time to add this info to Community.Testing page
vmassol - (10:28): ok gr8
florinciu joined #xwiki at 10:30
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 ?
tmortagne - (10:33): does not seems to exists any context variable with the panel
vmassol - (10:34): don't we have a $panelDoc or somethinf?
vmassol - (10:34): it would be defined in macros.vm
vmassol - (10:34): (if it exists)
tmortagne - (10:34): i already looked and nothing is set in displayPanel
tmortagne - (10:34): displaypanel
tmortagne - (10:35): but in case i'm asking in case i did not seen something
vmassol - (10:35): tmortagne: I see this:
vmassol - (10:35): #if ($paneldoc && $paneldoc != "")
vmassol - (10:35): so it must be set somewhere I guess
vmassol - (10:35): checking
tmortagne - (10:36): it's a local variable of the macro
tmortagne - (10:36): a velocity variable
tmortagne - (10:36): i don't know if you can access this variable in the panel itself
vmassol - (10:36): #set ($paneldoc = $xwiki.getDocument($name))
vmassol - (10:36): can you try?
tmortagne - (10:36): but anyway i want to access this information from java
vmassol - (10:36): ah
tmortagne - (10:37): basically i would need some "realcurrentdoc" context entry
Denis - (10:38): tmortagne: I have used vcontext.get('panel') or $panel for that, but this is clearly a hack IMO
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
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
tmortagne - (10:41): (the one that take the source as string)
Denis - (10:42): than you ask to wrong question, and my feeling is that there is no answer currently
Denis - (10:42): there is a serious issue in the way templates, panels, and other interface element are displayed...
tmortagne - (10:42): i knows there is nothing to know the real current document
tmortagne - (10:43): i just trying to find a way to resolve it for now
Denis - (10:43): good luck !
tmortagne - (10:43): yes...
CalebJamesDeLisl - (10:51): vmassol: Any comment on my secure filesystem access proposal? I think it is relevant to your work on components.
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
CalebJamesDeLisl - (10:55): Ok
sdumitriu joined #xwiki at 10:58
sdumitriu - (11:05): jvelociter: Where's the noscript macro?
jvelociter - (11:05): not uploaded right now, I had issues with internet yday
jvelociter - (11:05): but I will do that now
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?
mariusbutuc joined #xwiki at 11:10
jvelociter - (11:11): sdumitriu: it's there now:)
tmortagne - (11:14): jvelociter: we should probably add a remove method in org.xwiki.rendering.block.Block
jvelociter - (11:14): tmortagne: agreed, I looked for it initially ;)
jvelociter - (11:15): (forgot to report it after the training session)
tmortagne - (11:15): just one thing, this macro should be a java macro IMO
tmortagne - (11:15): you would not need to render it back to xwiki/2.0 syntax
tmortagne - (11:17): also your macro support only xwiki/2.0 syntax
tmortagne - (11:17): in java it would support any syntax
jvelociter - (11:17): tmortagne: yes it would be better. Originally it was an illustration of wiki macros and rendering APIs
jvelociter - (11:17): it's not really meant to be used as is
tmortagne - (11:18): i think we should have a way to return java Block object in wiki macro
tmortagne - (11:19): it's not difficult, we just need something like xcontext.macro.return(blocks)
tmortagne - (11:19): it would havoid having to render blocks to reparse it if you already have them
tmortagne - (11:20): creating an issue for it
jvelociter - (11:22): ok
tmortagne - (11:25): ( http://jira.xwiki.org/jira/browse/XWIKI-5124 )
mflorea left at 11:26 (Quit: Leaving.
jvelociter - (11:46): interesting post on facebook JS perf http://ajaxian.com/archives/facebook-javascript-jsconf
bougie - (11:54): tmortagne: hello
bougie - (11:54): my auth is working :)
tmortagne - (11:54): bougie: hi
tmortagne - (11:54): ha great :)
plunden1 joined #xwiki at 11:55
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.
CalebJamesDeLisl - (11:58): A concept that I find interesting is sandboxing user script so we don't have to filter out all possible XSS.
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.
sdumitriu - (12:04): Not quite
sdumitriu - (12:04): In IE, which is the most troublesome, AJAX is done with an activeX object
sdumitriu - (12:05): And I doubt you can get rid of them that easily
sdumitriu - (12:05): Plus, you would prevent ALL code from doing Ajax, since there is only one global scope
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.
CalebJamesDeLisl - (12:07): But the IE issue is a breaker.
CalebJamesDeLisl - (12:08): There is also Caja rewriter but I haven't looked into it much
vmassol - (12:12): guys the jira service is going to be restarted by the infra team to apply a security patch
jvelociter - (12:13): (1:00 pm Paris time)
CalebJamesDeLisl - (12:14): vmassol: Do you have any specific questions about the secure filesystem access proposal?
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
vmassol - (12:15): (one week of holiday + one week business travel + one week preparation of a training + my stuff I work on,e tc)
vmassol - (12:15): I think you should make some more global architecture proposal
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.
vmassol - (12:16): CalebJamesDeLisl: you're workong on how many things at once? :)
vmassol - (12:16): actions, invitation, security, perfs, etc ;)
vmassol - (12:17): on my side
vmassol - (12:17): I need a vision of where we want to go in the new architecture re general authentication/authorization too
vmassol - (12:17): before I can answer some specific question in one specific area
vmassol - (12:18): sorry got to go again (was in meeting and now need to go for lunch...)
CalebJamesDeLisl - (12:18): Ok. actions and js performance seem to be stalled at the moment, everything else is waiting on the list.
florinciu left at 12:28 (Read error: Connection reset by peer
florinciu joined #xwiki at 12:34
CalebJamesDeLisl - (12:35): Hmm, apparently I never send the mail asking how to add the email inviter to the sandbox. Just sent.
mflorea joined #xwiki at 12:37
nickless left at 13:02 (Ping timeout: 245 seconds
nickless joined #xwiki at 13:27
jvdrean joined #xwiki at 13:41
gvallarelli - (13:47): so the 16 proposal win
sdumitriu - (13:47): Yes
sdumitriu - (13:47): But it still needs to be changed
sdumitriu - (13:48): So, do you know what your chances are to get a slot?
gvallarelli - (13:49): I don't know anything... Except that proposal sent to nescent are 30 and there are a lot of good ones
arkub joined #xwiki at 13:50
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
sdumitriu - (13:50): Yes, best thing is not to worry too much
sdumitriu - (13:51): The outcome will be the same wether you worry or relax
gvallarelli - (13:51): yep
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
mariusbutuc left at 13:57 (*.net *.split
xipe left at 13:57 (*.net *.split
mariusbutuc joined #xwiki at 14:03
xipe joined #xwiki at 14:03
plunden left at 14:17 (Ping timeout: 276 seconds
florinciu left at 14:30 (Read error: Connection reset by peer
florinciu joined #xwiki at 14:31
arkub left at 14:34 (Ping timeout: 258 seconds
silviar left #xwiki at 14:41
CalebJamesDeLisl - (14:50): Is the standard for translation keys supposed to be camel case or not?
glerouge - (14:50): not necessarily
sdumitriu - (14:51): Caleb: YES, YES!
sdumitriu - (14:51): Don't listen to glerouge
CalebJamesDeLisl - (14:51): Ok, I was wondering if we were going to camel case or from it :)
sdumitriu - (14:52): To
glerouge - (14:52): I thought it was some.translation.key=Some translation value
glerouge - (14:52): where's CamelCase in that?
CalebJamesDeLisl - (14:53): some.thisVeryCoolTranslation.key=Translation...
glerouge - (14:53): for a real one? ;)
CalebJamesDeLisl - (14:53): xe.blog.manageCategories.comment.updatedParent=Updated category parent
glerouge - (14:54): I'm going to go bury myself and I'll be back
CalebJamesDeLisl - (14:54): :)
mariusbutuc left at 14:55 (Quit: Leaving.
evalica left at 15:52 (Read error: Connection reset by peer
Enygma` left at 15:52 (Quit: Leaving.
arkub joined #xwiki at 16:16
arkub left at 16:17 (Remote host closed the connection
arkub joined #xwiki at 16:24
florinciu left at 16:30 (Read error: Connection reset by peer
florinciu joined #xwiki at 16:32
nickless left at 16:36 (Ping timeout: 265 seconds
CalebJamesDeLisl - (16:53): Any suggestion for what translation keys should be named for the liveValidation translations?
CalebJamesDeLisl - (16:54): platform.js.validation.okMessage=Ok
CalebJamesDeLisl - (16:54): ?
sdumitriu - (16:56): Caleb, can you make a patch?
sdumitriu - (16:57): And bug me until I review it?
sdumitriu - (16:57): platform, ok
sdumitriu - (16:57): I'm not sure about js
sdumitriu - (16:57): Better not
CalebJamesDeLisl - (16:57): A patch for validation translations?
sdumitriu - (16:57): validation, ok
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
vmassol - (16:58): (and i don't recall details of that discussion or whether we reached a conclusion)
vmassol - (16:58): we do have a rule for naming config properties though
sdumitriu - (16:58): We have some rules, but the rules aren't very precise
CalebJamesDeLisl - (16:58): The other day you referenced an email thread but it was for configuration files.
sdumitriu - (16:58): They just say that it should be application.part.key
sdumitriu - (16:59): From there, it's common sense
sdumitriu - (16:59): Like any naming rule, there are just some suggestions that leave plenty of room for variations
gvallarelli left at 16:59 (Ping timeout: 240 seconds
CalebJamesDeLisl - (17:00): and variations there are ;)
plunden1 left #xwiki at 17:00
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.)
CalebJamesDeLisl - (17:02): So. platform.validation.okMessage=Ok?
sdumitriu - (17:02): Looks good so far
sdumitriu - (17:02): maibe validMessage?
sdumitriu - (17:02): ok is not very proper...
CalebJamesDeLisl - (17:03): It's going to spend some time in the sandbox as a language pack first anyway.
sdumitriu - (17:03): Or, depending on how many messages there are, maybe:
sdumitriu - (17:03): platform.validation.messages.ok
CalebJamesDeLisl - (17:04): I only have ok, fieldMandatory and invalidEmail at the moment.
vmassol - (17:04): naming stuff is the hardest part of programming ;)
sdumitriu - (17:05): vmassol: It's easy, just use i and j
sdumitriu - (17:05): :)
CalebJamesDeLisl - (17:05): You would think coming up with names was easy looking at the translations document (or any api for that matter)
sdumitriu - (17:08): The existng translations are not good inspiration
sdumitriu - (17:08): There are probably more than 5 different naming strategies in there
CalebJamesDeLisl - (17:09): Yea I think there is a definite need for having a way to change translation keys without breaking old code.
vmassol - (17:15): that's not really possible caleb, by definition :)
tmortagne - (17:16): well we could maintain some kind of retro compatibility mapping, oldkey=newkey
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
CalebJamesDeLisl - (17:16): What tmortagne said.
vmassol - (17:16): yes retro is possible, ie aliases
tmortagne - (17:16): yep aliases
tmortagne - (17:16): aliases could be useful for other use cases
vmassol - (17:17): yes we talked about it tmortagne
vmassol - (17:17): btw I think this is supported already for our configuration files AFAIR
vmassol - (17:17): (it comes from commons-configuration)
tmortagne - (17:17): we cool look at what commons-configuration do then
tmortagne - (17:18): s/cool/could/
vmassol - (17:18): let me find the link
vmassol - (17:18): it transforms them into variables AFAIR
vmassol - (17:18): something like:
vmassol - (17:18): my.key1 = value1
vmassol - (17:18): my.key2 = ${my.key1}
vmassol - (17:18): let me find it
vmassol - (17:19): it' called variable interpolation
vmassol - (17:19): http://commons.apache.org/configuration/userguide/howto_basicfeatures.html#Variable_Interpolation
vmassol - (17:20): so the good news is that we can use this retro compat feature for our new config files :)
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
tmortagne - (17:21): if there is a reusable l10n value parser we should use it for l10n, would be more consistent
tmortagne - (17:21): that way it would fit my need for rendering
vmassol - (17:22): nice new maven refactoring in IDEA: http://bit.ly/9v26zt
vmassol - (17:23): I don't know any off the top of my head
vmassol - (17:23): well
vmassol - (17:23): EL is one
vmassol - (17:23): velocity is another
vmassol - (17:24): (el: http://java.sun.com/javaee/5/docs/api/javax/el/package-summary.html)
vmassol - (17:25): and a lot of others
vmassol - (17:27): http://stackoverflow.com/questions/1412132/use-property-in-a-properties-file
CalebJamesDeLisl - (17:27): Is the message getter in rendering documented? I couldn't find it.
vmassol - (17:28): so we could use commons configuration for reading translation property files too
vmassol - (17:29): ie use xwiki-configuration
CalebJamesDeLisl - (17:30): Hmm, looks like code reduction, and it's code which needs filesystem access.
vmassol - (17:33): (would need some sort of bridge between ResourceBundle and commons configuration)
vmassol - (17:35): reading http://n4.nabble.com/Commons-Configuration-for-i18n-td999273.html
mflorea left at 17:36 (Quit: Leaving.
lucaa left at 17:37 (Quit: Leaving.
nickless joined #xwiki at 17:39
nickless left at 18:01 (Ping timeout: 276 seconds
florinciu left at 18:30 (Read error: Connection reset by peer
bougie - (18:51): tmortagne: if i give you my xwiki.cfg en my ldap schema, can you add my content to xwiki ldap page ?
bougie - (18:51): s/en/and
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)
tmortagne - (18:53): you have all right to modify the page on xwiki.org
jvdrean left at 19:01 (Quit: Leaving.
KermitTheFragger left at 19:09 (Quit: Leaving
arkub left at 19:13 (Ping timeout: 258 seconds
bougie - (19:18): sorry for my english :/
glerouge left at 19:19 (Quit: Leaving.
tmortagne - (19:24): bougie: i doubt it's working with empty xwiki.authentication.ldap.bind_DN and xwiki.authentication.ldap.bind_pass
bougie - (19:24): when it's empty, it's an anonymous connexion
bougie - (19:25): and with opends, you can list and read some attributs
tmortagne - (19:25): ha ok ineed i forgot about that since i always configure LDAP for LDAP server that does not alllow anonymous access :)
tmortagne - (19:26): you should probably say it
tmortagne - (19:26): describe a little more what it's doing
tmortagne - (19:26): also you should remove so default values:
tmortagne - (19:28): xwiki.authentication.ldap.validate_password=0
tmortagne - (19:28): xwiki.authentication.ldap.UID_attr=cn
tmortagne - (19:28): xwiki.authentication.ldap.password_field (only used with xwiki.authentication.ldap.validate_password=1)
tmortagne - (19:28): xwiki.authentication.ldap.update_user=1
tmortagne - (19:28): xwiki.authentication.ldap.groupcache_expiration=3600xwiki.authentication.ldap.mode_group_sync=always xwiki.authentication.ldap.trylocal=1
tmortagne - (19:28): xwiki.authentication.ldap.groupcache_expiration=3600
tmortagne - (19:28): xwiki.authentication.ldap.mode_group_sync=always
tmortagne - (19:28): xwiki.authentication.ldap.trylocal=1
tmortagne - (19:28): to make more clear what is specific to ApacheDS
tmortagne - (19:28): OpenDS sorry
tmortagne - (19:29): like it's done for "Apple Open Directory Server"
tmortagne - (19:39): bougie: great :)
tmortagne - (19:39): is uppercase I in "DIrectory" on purpose ? :)
tmortagne - (19:40): looking at the source remain me i need to convert this page to xwiki/2.0 syntax
tmortagne - (19:47): bougie: you have two different configurations for xwiki.authentication.ldap.bind_DN
tmortagne - (19:47): by bad
tmortagne - (19:47): missread
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 ?
tmortagne left at 20:00 (Quit: Leaving.
anamarias joined #xwiki at 20:14
anamarias left at 20:14 (Client Quit
anamarias joined #xwiki at 20:15
florinciu joined #xwiki at 20:18
kibahop joined #xwiki at 20:22
kibahop left #xwiki at 20:23
anamarias left at 20:53 (Quit: anamarias
florinciu left at 21:08 (Read error: Connection reset by peer
jvdrean joined #xwiki at 21:11
florinciu joined #xwiki at 21:37
anamarias joined #xwiki at 21:42
anamarias left at 21:45 (Client Quit
anamarias joined #xwiki at 21:48
anamarias left #xwiki at 21:50
Denis - (22:01): sdumitriu: would you want me to change the link into a button ?
sdumitriu - (22:02): Well, we're trying to keep the wiki accessible
sdumitriu - (22:02): This means that everything must work without javascript
sdumitriu - (22:02): So, the usual way to do it is:
sdumitriu - (22:02): - keep the href something that would work
Denis - (22:02): sdumitriu: agreed, but this .vm is already always in a lightbox
sdumitriu - (22:02): - add a listener from javascript
Denis - (22:03): it is not meant to be used outside of it, and would not work
sdumitriu - (22:03): Are you sure?
Denis - (22:03): <span class="buttonwrapper"><input class="button" type="submit" name="formactionsave" value="$msg.get("save")" onclick=" window.lb.l
Denis - (22:03): <span class="buttonwrapper"><input class="button" type="submit" name="formactioncancel" value="$msg.get("cancel")" onclick=" window.
Denis - (22:04): oups
Denis - (22:04): <span class="buttonwrapper"><input class="button" type="submit" name="formactionsave" value="$msg.get("save")" onclick=" window.lb.lbSaveForm();"/></span>
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>
Denis - (22:04): here is the form submits
Denis - (22:05): so in a lightbox or useless
Denis - (22:05): this is why I have done so
Denis - (22:05): we could refactor this UI, but this is not my initial goal
Denis - (22:06): just want to avoid the lightbox being replaced by a fullscreen document when you pass over the lock
sdumitriu - (22:06): K
sdumitriu - (22:07): Then you could leave it as it is for the moment
sdumitriu - (22:07): And in the future we'll have to redo this whole part
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
sdumitriu - (22:10): Well, 2.2 is an old branch, and usually only critical bugfixes should be in
sdumitriu - (22:10): If you need it, you could apply it, though
Denis - (22:12): ok, thanks
nickless joined #xwiki at 22:50
plunden joined #xwiki at 22:53
florinciu left at 23:05 (Quit: Leaving.
vmassol left at 23:08 (Quit: Leaving.
florinciu joined #xwiki at 23:10
Denis left at 23:27 (Quit: Leaving.
jvdrean left at 23:50 (Quit: Leaving.
florinciu left at 23:59 (Read error: Connection reset by peer
