IRC Archive for channel #xwiki

abusenius left at 00:07 (Quit: Konversation terminated!
abusenius joined #xwiki at 00:08
anamarias left at 01:20 (Quit: anamarias
abusenius left at 01:38 (Quit: Konversation terminated!
lucaa left at 02:22 (Ping timeout: 265 seconds
mflorea joined #xwiki at 06:33
Denis left at 07:04 (Read error: Connection reset by peer
Denis joined #xwiki at 07:10
vmassol joined #xwiki at 07:35
kibahop joined #xwiki at 07:54
kibahop left #xwiki at 07:54
kibahop joined #xwiki at 08:23
plunden joined #xwiki at 08:27
plunden left #xwiki at 08:28
plunden joined #xwiki at 08:28
sburjan joined #xwiki at 08:32
kibahop left #xwiki at 08:39
vmassol - (08:53): sburjan: good morning
vmassol - (08:53): I've fixed a few things on the http://platform.xwiki.org/xwiki/bin/view/Features/DocumentLifecycle page you can check the history
vmassol - (08:53): one more thing to fix that I'lll let you do is fix the Delete section
vmassol - (08:53): it says " This option is non reversible so be very careful when you use it."
vmassol - (08:53): this is not correct
vmassol - (08:54): it'll go to the trash
vmassol - (08:54): and you can get it back
sburjan - (08:54): hello vmassol
vmassol - (08:54): we need some text for this + screenshots
vmassol - (08:54): and explain how to undelete
sburjan - (08:54): okay, you want me to create a section on DocumentLifecylce to explain how to undelete a Page ?
vmassol - (08:54): no
vmassol - (08:55): you can put it in the Delete seciton
vmassol - (08:55): section
sburjan - (08:55): okay
vmassol - (08:56): I think this needs rewording too:
vmassol - (08:56): "A rename feature is available in XWiki. Its effect is to change the page name (that is, you get http://<server>/xwiki/bin/View/NewSpace/NewPageName instead of http://<server>/xwiki/bin/View/OldSpace/OldPageName)"
vmassol - (08:57): the rename will perform 2 refactoring:
vmassol - (08:57): - update backlinks
vmassol - (08:57): - update parent information
silviar joined #xwiki at 09:01
sburjan - (09:08): It's just that I can't find the Trash
vmassol left at 09:16 (Quit: Leaving.
vmassol joined #xwiki at 09:23
Enygma` joined #xwiki at 09:29
vmassol - (09:31): sburjan: just do a test and delete a page, you'll see the screen that you get
sburjan - (09:31): found it, now creating the screens
arkub joined #xwiki at 09:32
vmassol - (09:32): silviar, sburjan:I think we're missing an application on code.xwiki.org
vmassol - (09:33): the XWiki Enterprise application itself
vmassol - (09:33): which means the following features are not documented right now:
vmassol - (09:33): - dashboard
vmassol - (09:33): - recent changes
jvdrean joined #xwiki at 09:34
vmassol - (09:34): - alldocs
vmassol - (09:34): - spaces
sburjan - (09:34): hmmmm
vmassol - (09:34): - color themses too
sburjan - (09:34): spaces as far as I know are documented because I created some screen shots
sburjan - (09:34): how to add a new space, etc
silviar - (09:34): For color themes we have an application page; spaces are here http://platform.xwiki.org/xwiki/bin/view/Features/Spaces
vmassol - (09:35): sburjan: no, not the space feature
vmassol - (09:35): the Spaces page
sburjan - (09:35): oh
vmassol - (09:35): http://localhost:8080/xwiki/bin/view/Main/Spaces
vmassol - (09:36): silviar: ok this is wrong
vmassol - (09:36): same discussion as we've had this morning
vmassol - (09:36): it's not fully wrong
vmassol - (09:36): just the space dashboard shouldn't be documented there
vmassol - (09:36): since it's not a platform feature
vmassol - (09:36): I mean this part "On your wiki's homepage you will see a list of all available spaces:"
vmassol - (09:37): and also the space creation from that dashboard
silviar - (09:37): yes, you're right; we'll explain the spaces dashboard & creation on a separate XE Application page and link that page later from Features.Spaces
silviar - (09:38): for more details
vmassol - (09:38): is color themese doc'ed somewhere?
vmassol - (09:38): maybe in the colibri skin
vmassol - (09:38): which is not the right place in this case
vmassol - (09:38): btw colorthemes should be moved to its own app I believe
vmassol - (09:38): sdumitriu: do you remember why you put it in XE?
silviar - (09:38): http://code.xwiki.org/xwiki/bin/view/Applications/ColorThemeApplication
vmassol - (09:39): silviar: ok leave it here for now since it might well be where we want it to be
vmassol - (09:39): need to get agreement from sdumitriu
vmassol - (09:39): (right now in the code it's in the XE app and not a standalone app)
silviar - (09:40): We discussed this when the color themes where updated and at that time a new application seemed the right solution
silviar - (09:40): ok
vmassol - (09:40): re dashboard we could also decide to have an app for this actually and it could contain:
vmassol - (09:40): - recent changes
vmassol - (09:40): - dashboard
vmassol - (09:40): - spaces
vmassol - (09:40): - alldocs
vmassol - (09:41): sdumitriu: wdyt?
vmassol - (09:41): jvdrean, jvelociter, Denis: wdyt?
vmassol - (09:42): actually we agreed a long time ago to separate all XE pages into separate apps
vmassol - (09:42): we just haven't finished it
vmassol - (09:43): in jira I called this app "navigation" but we might want a better name. Dashboard isn't so bad since it's about dashboards.
Denis - (09:44): vmassol: +1 for an application for everything
vmassol - (09:44): Denis: do you agree to have one app for:
vmassol - (09:44): - recent changes
vmassol - (09:44): 9:40
vmassol - (09:44): - dashboard
vmassol - (09:44): 9:40
vmassol - (09:44): - spaces
vmassol - (09:44): 9:40
vmassol - (09:44): - alldocs
vmassol - (09:44): (a single app that is)
vmassol - (09:44): what would you call it?
vmassol - (09:44): is dashboard a fair name?
Denis - (09:44): vmassol: not bad
evalica joined #xwiki at 09:45
vmassol - (09:45): silviar: let me get agreement for this app and I'll code it and then we can document it as  new app
silviar - (09:45): ok
sburjan - (09:46): vmassol, : take a look atthe page
vmassol - (09:46): so we won't need a xe app
silviar - (09:46): Maybe sburjan can start on a draft and then we just move it
vmassol - (09:46): sburjan: it's not correct
vmassol - (09:46): you documented alldocs
vmassol - (09:46): which isn't part of platform
vmassol - (09:46): as I said
vmassol - (09:46): just dleete a page
vmassol - (09:46): you'll get the trash for the page
silviar - (09:47): I'm showing him right now
vmassol - (09:47): ok thanks silviar
jvdrean - (09:47): +0 (I think dashboards could be a feature of XE)
vmassol - (09:48): jvdrean: wdym? I'll be part of XE of course
vmassol - (09:48): s/I'll/it'll/
vmassol - (09:48): or are you saying it has no menaning outside of XE
vmassol - (09:48): like I'm creating a wiki for myself
vmassol - (09:49): and I want these dashboards
vmassol - (09:49): are you saying this won't happen?
vmassol - (09:49): (in this case we can put back all our apps in one app ;))
vmassol - (09:50): note: I was thinking we could put our XEM dashboards in there too in the future
vmassol - (09:50): (or maybe not)
vmassol - (09:51): jvdrean: or are you thinking about the extra release work? :)
jvdrean - (09:51): I've put a +0 because I know this is a endless debate :)
vmassol - (09:51): I just want to know your position
vmassol - (09:51): since it wasn't clear
jvdrean - (09:51): I think it's overkill and I think it could be documented in XE wiki
vmassol - (09:51): you'd prefer a single XE app?
Denis - (09:54): vmassol: for sure, multiplying the app may increase release work, on the other hand, if these are stable, this is not true
florinciu joined #xwiki at 09:54
vmassol - (09:54): re the future, I feel it makes sense to have separate apps with the extension manager
Denis - (09:56): personnaly, I prefer separate apps as well, I already remove part of XE like the blogs in my initial installation in production, to be able to replace it by an implementation that suit me better
Denis - (09:56): so having separate apps allow more flexibility
jvdrean - (09:57): I think optional apps deserve their own lifecycle but I know we have different opinions about what's optional in XE :) (re the fact that for XE is the platform, I haven't seen a project not using XE wiki)
jvdrean - (09:57): s/that for/that for me/
vmassol - (09:58): xe is a platform packaging if you prefer
vmassol - (09:58): but you can't say it's the platform
vmassol - (09:58): for ex talk to julien who's using the xwiki rendering engine
vmassol - (09:59): he's not using anything else
vmassol - (09:59): he's using a piece of the platform
vmassol - (09:59): ok I know it's a special case but it would be great to have each piece be as independent as possible from the rest
jvdrean - (09:59): I know your PoV and I won't fight, thus the +0
vmassol - (10:00): XE is simply a bundling of apps/config
jvdrean - (10:00): (and yes the rendering is a special case :) )
vmassol - (10:00): the thing is
vmassol - (10:00): we had several products before
vmassol - (10:00): so platform made a lot of sense to be separated
vmassol - (10:01): I'm sure I could be convinced to remove XE
vmassol - (10:01): and consider xwiki as a runtime platform only
vmassol - (10:01): (with the exception of rendering + wysiwyg)
vmassol - (10:01): (and maybe other components later on)
vmassol - (10:02): (re components that'll be possible when there's a component manager in the JDK - but that's another discussion ;))
jvdrean - (10:02): I already failed at convincing you when we talked about the future svn reorg
anamarias joined #xwiki at 10:02
vmassol - (10:02): jvdrean: you should keep trying
vmassol - (10:02): I wasn't strongly against it
vmassol - (10:03): my main comment I think is that the xwiki.org project should offer a usable enterprise wiki
vmassol - (10:04): and not jsut a platform
vmassol - (10:04): a bit like eclipse if you want
vmassol - (10:04): so if we name the main product of xwiki.org XWiki Platform then it's not very appealiling for users
tmortagne joined #xwiki at 10:04
vmassol - (10:04): it'll appeal only to developers
vmassol - (10:05): we could decide that's what we want though
vmassol - (10:05): but I think that what we have now goes beyond just a bare platform
vmassol - (10:05): we have refined UIs that form a usable product
vmassol - (10:05): if we can solve this point we could definitely agree on something
tmortagne1 joined #xwiki at 10:06
tmortagne left at 10:06 (Read error: No route to host
tmortagne1 left at 10:08 (Client Quit
mariusbutuc joined #xwiki at 10:08
jvdrean - (10:12): the way I'd present it is "XWiki Enterprise is both an enterprise wiki and a web dev platform, you can get XE and develop a project on top of it. It's core is also made of reusable components that you can get separately and use in your own project". I wouldn't say "There's XWiki Enterprise and XWiki Platform, you can get the second and build your own project on top of it. Also note that XWiki Platform is made of smaller reusable
vmassol - (10:13): ok so you'd keep XE and remove platform
vmassol - (10:13): not the other way around
jvdrean - (10:13): exactly
vmassol - (10:14): so you wouldn't be able to get just some pieces
vmassol - (10:14): it's an all or nothing
vmassol - (10:14): you get XE and you remove stuff if you need to
tmortagne joined #xwiki at 10:14
vmassol - (10:15): but not in an organized way
mflorea left at 10:15 (Quit: Leaving.
vmassol - (10:15): meaning you cannot say "remove this feature"
vmassol - (10:15): you'd need to manually remove pages one by one
vmassol - (10:15): right?
vmassol - (10:15): the idea of the extension manager is to list all installed features in some admin page
jvdrean - (10:15): I'd keep an organization similar to the one we currently have
jvdrean - (10:16): allowing to exclude the blog app for example, which is not coupled to the other pieces
jvdrean - (10:16): but I would ask the question about the admin app
jvdrean - (10:17): it's tightly coupled to many other pieces and I often find myself doing lockdowns in xe branches for it
lucaa joined #xwiki at 10:18
vmassol left at 10:20 (Ping timeout: 276 seconds
vmassol joined #xwiki at 10:29
abusenius joined #xwiki at 10:31
silviar - (10:34): vmassol: wdyt about adding the part on creating templates to the "Document Lifecycle" page instead of "Page editing"? I can talk about the template creation after the description on how you create an empty wiki page
CalebJamesDeLisl - (10:57): Good morning. What's the status on Alex's 2.0 renderer patch?
CalebJamesDeLisl - (10:58): Default is no nested scripts.
CalebJamesDeLisl - (11:00): The config key is: rendering.macro.script.nestedscripts.enabled
CalebJamesDeLisl - (11:00): We have switched to camel case in xwiki.properties haven't we.
tmortagne - (11:01): CalebJamesDeLisl: not exactly, only for the last part
CalebJamesDeLisl - (11:01): Ok, so that key is good?
tmortagne - (11:01): looks ok to me
CalebJamesDeLisl - (11:02): I don't like this but I don't see a good way around at the moment:   } else if ("include".equals(parentId)) {
CalebJamesDeLisl - (11:02): It's not an api.
tmortagne - (11:03): yes but that's already how include macro is manager round currently so it's not worst that what's already exists, should be improved latter
CalebJamesDeLisl - (11:03): vmassol: Your opinion?
tmortagne - (11:03): s/round/around/
tmortagne - (11:04): i prefer that that introducing a not well though api
mflorea joined #xwiki at 11:13
vmassol - (11:16): silviar: yes
vmassol - (11:17): (that's what I meant)
silviar - (11:17): ok
vmassol - (11:17): (I mixed the name of the pages)
mflorea left at 11:17 (Client Quit
CalebJamesDeLisl - (11:17): Are we going to remove jira issue numbers from the (nested script) patch? It references XWIKI-5275
tmortagne - (11:18): CalebJamesDeLisl: i already asked abusenius to remove that yesterday
mflorea joined #xwiki at 11:18
tmortagne - (11:18): as well as some other womments
tmortagne - (11:18): comments
CalebJamesDeLisl - (11:19): He switched from the secret issue to the public one.
tmortagne - (11:19): abusenius: did you took care of theses ? (i did not cheked)
CalebJamesDeLisl - (11:20): It's no problem for me to remove them when committing, I will also have to document it in xwiki.properties
abusenius - (11:20): good morning everyone
abusenius - (11:20): no, I didnt
tmortagne - (11:21): CalebJamesDeLisl: i was not only about this comment
Enygma` left at 11:21 (Quit: Leaving.
Enygma` joined #xwiki at 11:21
CalebJamesDeLisl - (11:21): What else is there?
tmortagne - (11:22): there is some codestyle modification not related with this issue
tmortagne - (11:22): let me find my comments
CalebJamesDeLisl - (11:22): Yup, I can remove that from the patch.
CalebJamesDeLisl - (11:23): Hmm, there's an unclosed <p> block in ScriptMacroConfiguration javadoc
tmortagne - (11:23): (02:23:30 PM) <moi>: also you have a modification in MacroTransformation that is just codestyle
tmortagne - (11:24): (02:37:35 PM) <moi>: btw don't put comment with jira issue number in it, if there is not logical explanation for the code it should not be there. In this case it's more an improvement of what i done for XWIKI-5230 so it's really not directly related to XWIKI-5275
CalebJamesDeLisl - (11:25): Alex do you want to make these changes and upload a new patch with the changes?
tmortagne - (11:25): CalebJamesDeLisl: also don't forget to fix the @since tags before committing
tmortagne - (11:25): (abusenius could not know in which version it would be committed at the end)
CalebJamesDeLisl - (11:25): Ahh you saw my "fix @since" commit ;)
tmortagne - (11:26): CalebJamesDeLisl: i was only talking about abusenius patch ;)
abusenius - (11:26): I fixed @since to 2.4M2 in the last patch alread
abusenius - (11:26): y
tmortagne - (11:26): ok
abusenius - (11:26): and I guess its faster if you change it, Caleb
CalebJamesDeLisl - (11:27): So TODO: remove codestyle change to MacroTransformation, add configuration param to xwiki.properties.vm, remove XWIKI-*, remove stray <p> tag. anything else?
abusenius - (11:27): there is only one style change, in wrapInMacroMarker
abusenius - (11:27): the removed import is needed
abusenius - (11:28): otherwise there is fan out error
CalebJamesDeLisl - (11:28): Yup.
tmortagne - (11:28): CalebJamesDeLisl: about MacroTransformation just revert the file after applying teh patch, there is no modification exctep codestyle in it actually
abusenius - (11:28): there is a new comment :)
tmortagne - (11:29): sure but tht would be another committ
CalebJamesDeLisl - (11:29): I was going to delete that part from the diff file, same end.
tmortagne - (11:29): it has nothing to do with your patch
abusenius - (11:29): true
tmortagne - (11:29): i can commit it now if you absolutely want it ;)
abusenius - (11:30): yes I do :)
tmortagne - (11:30): ok :)
abusenius - (11:30): hate missing comments
CalebJamesDeLisl - (11:31): Hey, fix a bunch of comments, especially in xwiki.api.* and I will definitely commit that.
abusenius - (11:31): anyway, I think both 1.0 and 2.0 script fixes should also be backported to 2.3.1 and 2.2.something
tmortagne - (11:32): we don't support 2.2 anymore
abusenius - (11:32): ah ok, then 2.3.1
abusenius - (11:32): since we wanted to do an advisory etc.
abusenius - (11:33): are there more changes since 2.3.1?
CalebJamesDeLisl - (11:33): isScriptNested always returns false if isScriptNestingEnabled  seems like it shouldn't lie.
CalebJamesDeLisl - (11:33): Ok, fanout violation. Fine it should lie.
abusenius - (11:34): yea, that was the reason :)
CalebJamesDeLisl - (11:34): Should I add a TODO comment that the almost fanout violation should be refactored?
abusenius - (11:35): I guess so, its not nice
tmortagne - (11:36): yep
CalebJamesDeLisl - (11:42): What happens here? @param <P> the type of macro parameters bean.
CalebJamesDeLisl - (11:42): do we get an html <p> block?
anamarias left at 11:49 (Quit: anamarias
abusenius - (11:50): thats what eclipse generates, and at least in eclipse javadoc preview it seems to display what needed
CalebJamesDeLisl - (11:51): Ahh, I got rid of the unclosed <p> block because it didn't seem right. Above is something which had existed before, javadoc must escape it when it's after a @param tag.
CalebJamesDeLisl - (11:56): Ok, changes made. Everyone's on board with this? vmassol your silence is taken as acquiescence.
tmortagne - (12:03): CalebJamesDeLisl: @param is
tmortagne - (12:03): @param paramname descrciption text
tmortagne - (12:03): so here <P> is the param name and not part of the description of teh parameter so i don't see why it should be escaped
tmortagne - (12:04): that's the description of the generic type and AFAIK it's correct like that
CalebJamesDeLisl - (12:04): Yea, I figured javadoc would handle it correctly, it was there so I didn't touch it.
CalebJamesDeLisl - (12:04): BTW: committed.
CalebJamesDeLisl - (12:05): On to the test.
CalebJamesDeLisl - (12:06): abusenius: You can make your tests a lot faster by not edit, save, etc.
tmortagne - (12:07): does this really need an integration test ? unit test seems enough IMO
CalebJamesDeLisl - (12:08): It's not unit tested, he was having a problem parsing the error.
tmortagne - (12:08): at least for "Prevent nested script macros"
CalebJamesDeLisl - (12:09): abusenius: To make tests faster: getDriver().get(getUtil().getURL("Space", "Page", "preview", new HashMap<String, String>(){{put("content", "the content you want on the page");}});
abusenius - (12:10): I see, good idea
CalebJamesDeLisl - (12:10): Is there any way we can unit test this?
abusenius - (12:11): tmortagne: is it possible to use regex for matching in event/1.0 ? or can it be done differently?
tmortagne - (12:11): abusenius: no there is no regexp support in rendering test framework but you could do a "normal" unit test
tmortagne - (12:12): hmm you could also wrapp the macro
tmortagne - (12:12): and catch the exception
CalebJamesDeLisl - (12:12): I am partial to integration tests because they prove everything works. I'll apply this patch then we can add unit tests.
abusenius - (12:12): wdym wrap?
tmortagne - (12:12): to produce something "nicer" to match
tmortagne - (12:13): class VelocityMacroTest extends VelocityMacro
tmortagne - (12:13): and overwrite execute
abusenius - (12:13): ah, I see
tmortagne - (12:13): to change the exception by something else
tmortagne - (12:14): but pure junit/jmock test should not be too hard either
tmortagne - (12:14): that's usualy how we test for exception like that
tmortagne - (12:14): see IncludeMacroTest
tmortagne - (12:14): in include macro
tmortagne - (12:15): i added testIncludeMacroWithRecursiveInclude recently for example
tmortagne - (12:15): it's pretty much the same needs
abusenius - (12:16): looking..
abusenius - (12:17): yea, true
tmortagne - (12:18): CalebJamesDeLisl: "@version $Id$" looks like your svn client is not properly setup
tmortagne - (12:19): (Id is supposed to be automatically replaced by commit user and date)
CalebJamesDeLisl - (12:19): Hmm, it usually works. I always see my name and wonder how it got _there_.
arkub left at 12:19 (Quit: Leaving
tmortagne - (12:20): CalebJamesDeLisl: that's because in many file sdumitriu explicitely configured the file itself to for the svn client to do it
tmortagne - (12:20): but you are siupposed to setup you client to do it automatically for new files
CalebJamesDeLisl - (12:20): @version $Id: ScriptMacroConfiguration.java 29494 2010-06-16 10:03:02Z cjdelisle $
CalebJamesDeLisl - (12:21): Yea it's just not in the patch email.
sburjan - (12:21): vmassol, : I am updating the import/export function. Should I createscreens forboth skins ? (PS: They look very much the same)
vmassol - (12:22): sburjan: I'd no then
vmassol - (12:22): on the phone right now
sburjan - (12:22): ok
tmortagne - (12:23): CalebJamesDeLisl: http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script/ScriptMacroConfiguration.java
tmortagne - (12:23): i don't see it
CalebJamesDeLisl - (12:24): http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-rendering/xwiki-rendering-macros/xwiki-rendering-macro-script/src/main/java/org/xwiki/rendering/macro/script/DefaultScriptMacroParameters.java
CalebJamesDeLisl - (12:24): Not there either.
CalebJamesDeLisl - (12:24): I think you need to checkout in order to see it.
tmortagne - (12:24): CalebJamesDeLisl: i don't think so
tmortagne - (12:24): taht's something put by your client, in the file itself
tmortagne - (12:24): my client will not find it alone
CalebJamesDeLisl - (12:28): tmortagne: Have a look at this one: http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-plugins/trunk/lucene/src/main/java/com/xpn/xwiki/plugin/lucene/IndexFields.java
mariusbutuc left at 12:28 (Quit: Leaving.
tmortagne - (12:29): seems weird to me
CalebJamesDeLisl - (12:30): On your disk you'll see your name and the revision etc.
CalebJamesDeLisl - (12:30): It happens on checkout rather than commit.
CalebJamesDeLisl - (12:30): It confused me for a while too.
tmortagne - (12:32): indeed i was sure it was about commit especially since i seen it in some committs
CalebJamesDeLisl - (12:37): What you are seeing is the older revision because nobody ever clears the content between $ $.
CalebJamesDeLisl - (12:37): So you are often checking in the content with the last author.
CalebJamesDeLisl - (12:38): with the revision id string from the last author.
vmassol - (13:18): CalebJamesDeLisl: just done a review of your commit
vmassol - (13:18): (by mail)
vmassol - (13:18): (was on the phone the whole morning)
CalebJamesDeLisl - (13:19): Ahh, sorry for excluding you from the decision, you could have said you were on the phone and I would have waited.
vmassol - (13:19): np
vmassol - (13:19): it's easier to comment on a commit btw
CalebJamesDeLisl - (13:20): what do you think of isNestedScriptViolation?
vmassol - (13:21): did you see my comments?
CalebJamesDeLisl - (13:21): Yes.
vmassol - (13:21): I'm proposing something more generic and IMO more object-oriented
vmassol - (13:21): so there's no notion of "nestd script"
vmassol - (13:21): there's only a notion of validation
vmassol - (13:21): ScriptValidator
vmassol - (13:22): NestedScriptValidator
vmassol - (13:22): no more utils!
vmassol - (13:22): (I hate utils)
vmassol - (13:22): for me utils is like spaghetti code
CalebJamesDeLisl - (13:23): So rename ScriptUtils to NestedScriptValidator?
vmassol - (13:23): basically yes
CalebJamesDeLisl - (13:24): Or are you talking about removing everything and taking another approach?
vmassol - (13:24): nope
vmassol - (13:24): I've put the code!
vmassol - (13:24): in comment
vmassol - (13:24): :)
vmassol - (13:24): try {
vmassol - (13:24):  for (ScriptValidator validator : componentManager.lookupList(ScriptValidator.class)) {
vmassol - (13:24):      validator.validate(context); <-- will throw ScriptValidationException
vmassol - (13:24):  }
vmassol - (13:24): } catch (ScriptValidationException e) {
vmassol - (13:25):  throw new MacroExecutionException("Script failed to pass validations. Reason = [" + e.getMessage() + "]", e);
vmassol - (13:25): }
vmassol - (13:26): btw we might not need any config param with this
CalebJamesDeLisl - (13:26): No config param so it's always not allowed?
vmassol - (13:27): IMO there aren't a lot of use cases where you want it allowed and it the user really wants
vmassol - (13:27): it can be done by implementing a ScriptValidator that overrides the nestedscriptvalidator
vmassol - (13:27): (same hint)
CalebJamesDeLisl - (13:27): tmortagne: Didn't like that idea.
vmassol - (13:27): I think it was not presented in this manner
vmassol - (13:28): it's a small and focused component
vmassol - (13:28): ok what we could do if tmortagne doesn't agree is this;:
vmassol - (13:28): replace the config param
vmassol - (13:28): with a param config listing the validator hints to execute
vmassol - (13:28): by default it would contain one validator: "nested"
vmassol - (13:29): (validator hints = hints of the validators)
CalebJamesDeLisl - (13:29): What other possible validators might we ever have?
vmassol - (13:29): for ex
vmassol - (13:29): forbid using the ruby macro
vmassol - (13:29): I don't know
vmassol - (13:29): anything you want
vmassol - (13:29): forbid having some special content
vmassol - (13:30): we can pass more data in parameters to the vlaidator
CalebJamesDeLisl - (13:30): ruby should be forbidden but why not just remove the ruby macro, or comonoent-override it?
vmassol - (13:30): ok then it's not a good ex
vmassol - (13:30): but based on content it's a good one
vmassol - (13:30): or based on params
vmassol - (13:30): or based on the cycle of the moon
vmassol - (13:31): or based on the context , ie depending on what page you're on
vmassol - (13:31): so that for some special page you allow it
vmassol - (13:31): and not on other pages
vmassol - (13:31): I don't know
vmassol - (13:31): you can imagine whatever you want
CalebJamesDeLisl - (13:31): I worry about making something generic if we can't imagine another use for it.
vmassol - (13:31): my examples don't convince you?
CalebJamesDeLisl - (13:32): Is it a scriptValidator or a macroValidator?
vmassol - (13:32): macro validator would be my choice if we can make it at that level
vmassol - (13:32): I was just tryiong not to make big changes
vmassol - (13:32): to your commit
vmassol - (13:32): the change I proposed is really small
vmassol - (13:33): now as I was trying to arguye
vmassol - (13:33): for a more general mechanism
vmassol - (13:33): but nobody was listening, remmeber
vmassol - (13:33): :)
CalebJamesDeLisl - (13:33): If it's a MacroValidator then we can use it to decide who gets to run the html macro for ex.
vmassol - (13:33): my comment here
vmassol - (13:34): is only to get rid of this ugly util component
arkub joined #xwiki at 13:34
vmassol - (13:34): as quickly as possible
CalebJamesDeLisl - (13:34): What I heard from "general mechanism" was transformation which I think is technically impossible.
vmassol - (13:34): now if you want to discuss something more generic
vmassol - (13:34): I'm fine
vmassol - (13:34): nope
vmassol - (13:34): I didn't say that
vmassol - (13:34): I said transformation OR filter
vmassol - (13:35): I even said
vmassol - (13:35): that my pref was for Tx
vmassol - (13:35): and if not possible for filter
vmassol - (13:35): I still don' tknow if Tx is not possible
vmassol - (13:35): but again Im busy on other stuff
vmassol - (13:35): I've alrady spent a lot of time on this
CalebJamesDeLisl - (13:35): Ok, filter being a new concept that makes sense.
vmassol - (13:35): and you too
vmassol - (13:36): I wanted to kepp my comment general
vmassol - (13:36): not to spend time
vmassol - (13:36): but I guess I've been dragged into it
vmassol - (13:36): :)
CalebJamesDeLisl - (13:36): Ok, your change will be made.
CalebJamesDeLisl - (13:36): Anyway that Utils class was only ever going to have one util so I dodn't much like that either.
mariusbutuc joined #xwiki at 13:36
vmassol - (13:37): CalebJamesDeLisl: a macro validator would be great though for the future but this can wait a bit
vmassol - (13:38): although maybe it's not more work… I'll let you decide… :)
CalebJamesDeLisl - (13:38): Default: false (disabled) <-- better?
vmassol - (13:38): almost
vmassol - (13:38): :)
vmassol - (13:38): a sentence might be good too
vmassol - (13:38): does this mean that by default it's disabled?
vmassol - (13:38): false is certainly better than 0
CalebJamesDeLisl - (13:39): Ok.
vmassol - (13:39): but I don't know what this means in an interface
vmassol - (13:39): this is implementation
vmassol - (13:39): not interface IMO
CalebJamesDeLisl - (13:39): Good point, removing it entirely.
vmassol - (13:39): this too:
vmassol - (13:39): + * You can override the default values for each of the configuration properties below by defining them in XWiki's global
vmassol - (13:39): + * configuration file using a prefix of "rendering.macro.script" followed by the property name. For example:
vmassol - (13:39): + * <code>rendering.macro.script.nestedscripts.enabled = 1</code>
vmassol - (13:39): this is also implementation
CalebJamesDeLisl - (13:42): hmm s/isNestedScriptsEnabled/areNestedScriptsEnabled/
CalebJamesDeLisl - (13:42): no never mind, "is" is generic term for boolean
vmassol - (13:43): IMO we don't need this anymore
vmassol - (13:43): since it could be replaced by a list of validators to execute
vmassol - (13:43): unless we want to execute them all
vmassol - (13:43): in which casae we can remove the config param altogether
vmassol - (13:44): (depends on tmortagne for the param removal)
CalebJamesDeLisl - (13:44): I will remove it for now.
vmassol - (13:45): I'm for the less clutter possible
vmassol - (13:45): yes I think it's better to remove
vmassol - (13:45): and wait for someone to ask us about it
vmassol - (13:46): (especially since there's always a solution based on components)
sburjan - (13:54): vmassol : are you around ?
vmassol - (13:54): yes
sburjan - (13:54): check this out
sburjan - (13:54): http://platform.xwiki.org/xwiki/bin/view/AdminGuide/User%20Management
vmassol - (13:55): what do you want me to check?
sburjan - (13:55): Should I switch to Colibri screens
sburjan - (13:55): right ?
vmassol - (13:55): the fact that it's not documented at the right level?
sburjan - (13:55): yes
sburjan - (13:55): and the screens are old
vmassol - (13:55): - registration should go in the admin app (I think caleb put it there)
vmassol - (13:56): - user profile is in the admin app too I think
vmassol - (13:56): for now you could just redo the screens
vmassol - (13:56): till we complete this morning's discussion
vmassol - (13:57): yes colibri
vmassol - (13:57): and toucan when the screens are very different
vmassol - (13:57): (I think they're the same)
sburjan - (13:57): they are
sburjan - (13:57): okay
sburjan - (13:57): screens onlythen
tmortagne - (13:59): CalebJamesDeLisl, vmassol: I'm ok with list of validators, it's indeed nicer, i even have one more use case: the test for programming right which is done in all script macros except velocity one which i don't like the way it is currently
CalebJamesDeLisl - (14:00): Is @Requiring a list of validators ok or are we going to want to hot add them?
vmassol - (14:00): lookupList is always better I think
vmassol - (14:01): unless we really want a list based on configuration
tmortagne - (14:01): CalebJamesDeLisl: make it dynamic makes it ready for wiki componenents and extension manager
vmassol - (14:01): tmortagne: so you agree to drop the config part?
vmassol - (14:01): (otherwise it's anti-dynamic ;))
tmortagne - (14:02): vmassol: i did not say that
tmortagne - (14:02): the default is to test all validators
CalebJamesDeLisl - (14:02): where do I find lookupList? this is new to me.
vmassol - (14:02): CM
vmassol - (14:02): lookList + lookupMap
tmortagne - (14:03): CalebJamesDeLisl: in the ComponentManager you have several lokkp apis
vmassol - (14:03): tmortagne: so if the config is not defined all
vmassol - (14:03): else the list?
CalebJamesDeLisl - (14:03): Hmm, fanout.
tmortagne - (14:03): vmassol: yep
vmassol - (14:03): fine with me
vmassol - (14:03): default should be all
tmortagne - (14:03): yep
CalebJamesDeLisl - (14:06): does     public void validate(MacroTransformationContext) provide enough?
vmassol - (14:07): probably need macro data too
tmortagne - (14:07): CalebJamesDeLisl: you should also give parameters i think
vmassol - (14:07): content + params
tmortagne - (14:07): and probably content too
CalebJamesDeLisl - (14:07): What would the line look like?
CalebJamesDeLisl - (14:08): MacroTransformationContext context, String content, Object... parameters?
vmassol - (14:08): there's an object for params
tmortagne - (14:08): CalebJamesDeLisl: the macro parameters
tmortagne - (14:08): look at script macro
CalebJamesDeLisl - (14:08): Ok, I was about to ask where the params were coming from.
tmortagne - (14:08): isn't it a ScriptMacroValidator ?
vmassol - (14:08): in term of order
vmassol - (14:09): I'd use the exact same order as Macro.execute
vmassol - (14:09): for consistency
vmassol - (14:09): ok for SMV
tmortagne - (14:10): yep better follow Macro.execute
vmassol - (14:10): I'm still wondering if it wouldn't be better to do a MV right away
vmassol - (14:10): might not be more work
vmassol - (14:10): MV = MacroValidator
vmassol - (14:10): and will prevent a deprecation phase
vmassol - (14:11): which is always a pain
CalebJamesDeLisl - (14:11): If everything is internal why do we need a deprecation phase?
vmassol - (14:11): it's not internal
tmortagne - (14:11): it could
vmassol - (14:12): could = could be internal?
tmortagne - (14:12): we don't have to make it public interface
vmassol - (14:12): yes but then it's not a feature
vmassol - (14:12): tmortagne: wdyt about MV?
CalebJamesDeLisl - (14:12): I can't find LookupList, find-grep LookupList returns nothing.
tmortagne - (14:13): for now we want a nice way to protect from nested script macros, the goal is not to introduce this new feature, it can always be decided latter with more though maybe
vmassol - (14:13): MV sounds attractive to me and pretty generic
vmassol - (14:13): we juste need to decide what to pass to recognize the macro
vmassol - (14:13): s/we juste/we'd just/
vmassol - (14:14): you think it's too rushed?
tmortagne - (14:14): vmassol: yes MV is nice i just don't want to rush it too much since we don't really need it at this level
CalebJamesDeLisl - (14:14): There is no AbstractMacro.evaluate so how would it get run?
tmortagne - (14:14): CalebJamesDeLisl: it would be run before the call to execute
vmassol - (14:14): ok fine but I'm pretty sure we'll need it one day and since it's not more work
tmortagne - (14:14): in the MacroTrnasformation
tmortagne - (14:15): MacroTransformation
vmassol - (14:15): but ok we can do it in 2 steps
vmassol - (14:20): silviar: might be great to add nice icons for applications. For ex: http://enterprise.xwiki.org/xwiki/bin/view/Main/Features
sburjan - (14:20): vmassol : I have a question
vmassol - (14:20): (they can be picked from our icon set used on xwiki.org)
vmassol - (14:20): (there are only 2 icons defined for apps right now: search and tags)
vmassol - (14:21): s/silviar/silviar+sburjan/
silviar - (14:21): yes, they would look nice; I'll talk to Caty and Ciprian about it
vmassol - (14:21): you don't need to create them
vmassol - (14:21): since we're already using an icon set
silviar - (14:21): yes, but maybe they can pick the best for each app
vmassol - (14:21): thought you wanted them to create them
vmassol - (14:22): because picking them is easy but your call
sburjan - (14:22): http://platform.xwiki.org/xwiki/bin/view/AdminGuide/User%20Management#HChangingthepasswordforanyuser .At this section, t he trick with ?xpage=passwd ..wouldnt it be more simple to integrate in some interface rather than in some interface ?
vmassol - (14:23): sburjan: that's an old trick
vmassol - (14:23): should be removed
vmassol - (14:23): now that we have a UI for it
vmassol - (14:23): oh wait
vmassol - (14:24): that's for any user
sburjan - (14:24): for ANY, yes
sburjan - (14:24): and I don't find anywhere in the interface to change for ANY user
vmassol - (14:25): sburjan: just tested
vmassol - (14:25): it works fine
sburjan - (14:25): okay. but shouldn't this be moved to some interface ?
vmassol - (14:25): it is htere!
vmassol - (14:25): that's what I mean by "it works fine"
vmassol - (14:25): you just go the profile of the person for which you wish to change the pws
vmassol - (14:25): s/pws/pwd
vmassol - (14:26): and click on the change pwd button
vmassol - (14:26): :)
vmassol - (14:26): it cannot be more easy
vmassol - (14:26): :)
sburjan - (14:26): okay. I will remove the trick from the documentation then
vmassol - (14:26): yep
sburjan - (14:26): and explain these steps
sburjan - (14:26): ok
CalebJamesDeLisl - (14:27): Do we use camel case for component roles? Not thinking today.
vmassol - (14:29): "nested" should be enough no?
vmassol - (14:29): for a SMV
vmassol - (14:29): you're talking hint I presume
vmassol - (14:29): (not role)
CalebJamesDeLisl - (14:31): I was going to do nestedScript and them make ScriptMacroValidator interface be MacroValidator.
CalebJamesDeLisl - (14:32): Since then all we have to do is add the hook to validate other macros. Make sense?
evalica - (14:32): vmassol: I don't quite see the value of adding icons for each application - and is not very scalable - and we need to keep track of other icons that were set for other applications
evalica - (14:33): vmassol: k I get it now .. just for those /Main/Features - k
florinciu left at 14:34 (Quit: Leaving.
plunden left #xwiki at 14:49
sburjan left at 14:50 (Quit: Ex-Chat
tmortagne - (14:57): CalebJamesDeLisl: core build is broken, checkstyle error in script macro
tmortagne - (14:58): it does not like @todo, use a separated // TODO instead
CalebJamesDeLisl - (15:09): Ok, thanks.
bbc581 left at 15:38 (Quit: bbc581
evalica left #xwiki at 15:42
Enygma` left at 15:46 (Ping timeout: 240 seconds
silviar - (15:48): Hi! Can someone please take a look at this page? http://code.xwiki.org/xwiki/bin/view/Applications/AnnotationsApplication
silviar - (15:49): It seems I can't edit it inline
silviar - (15:49): And attaching an Icon to it doesn't work either
tmortagne - (15:54): silviar: same thing with object editor actually
tmortagne - (15:54): ha no the content is somwhere else i think
tmortagne - (15:55): silviar: go to platform:Features.Annotations page
tmortagne - (15:55): the way it's done is bad, the {{include document="platform:Features.Annotations" context="new"/}} should be in the object i think
silviar - (15:55): I see; :) and do you have an Idea how to go about adding the icon?
silviar - (15:56): I should copy the content to the page directly, right? From the features page
tmortagne - (15:56): i don't know why it's done that way, it's a mess
silviar - (15:57): I think it's done that way to make sure any changes done on one page are reflected in the other
silviar - (15:57): but there won't be a need for that
tmortagne - (15:57): code:Applications.PanelsApplication and platform:Features.Annotations page should be rethink for sure
silviar - (15:57): The features page will be much shorter
silviar - (15:57): and will point to the Application Page
tmortagne - (15:57): it does not make sense to have icons on http://code.xwiki.org/xwiki/bin/view/Applications/PanelsApplication
tmortagne - (15:57): *images
tmortagne - (15:58): since theses images are supposed to be on platform:Features.Annotations already
silviar - (15:59): I've discussed this earlier today with vmassol and we concluded we should keep most of the info on the Application page
silviar - (15:59): and only have a summary on the features page
tmortagne - (16:00): silviar: i'm talking about what is done technically now, i'm not talking about the result
tmortagne - (16:00): whatever you want to do there is no reason to duplicate images the way it's done currently
arkub left at 16:01 (Quit: Leaving
mariusbutuc left at 16:01 (Quit: Leaving.
tmortagne - (16:01): i don't understand why you have images attached to http://code.xwiki.org/xwiki/bin/view/Applications/PanelsApplication page
tmortagne - (16:02): the images should be where the content is
silviar - (16:02): you mean annotations, right?
tmortagne - (16:02): no
tmortagne - (16:02): i mean images
tmortagne - (16:03): look at attachements on the pages
tmortagne - (16:03): the image of this page are attached in both pages
vmassol - (16:03): jvdrean: thanks
vmassol - (16:03): :)
tmortagne - (16:03): the attachement in http://code.xwiki.org/xwiki/bin/view/Applications/PanelsApplication are useless
tmortagne - (16:03): s/attachement/attachements/
vmassol - (16:04): the panel wizard needs to be documented somewhere though
silviar - (16:06): Don't you mean annotations being both in platform:Features & code:Applications?
silviar - (16:06): :)
silviar - (16:06): and both pages having the same images attached?
silviar - (16:07): when in fact the content is stored in a single page?
tmortagne - (16:10): silviar: i don't know what you are calling annotations here but i'm only talking about attachements
tmortagne - (16:11): again there is no reason to have all the attachements i see on code:Applications page since theses are already on platform:Features
silviar - (16:13): ok :) By Annotations I meant the annotations page on code:Applications; we were talking about the same thing
silviar - (16:14): now the issue is how to I proceed to editing code:Applications.Annotations
silviar - (16:14): so that it's no longer dependent on features page
tmortagne - (16:14): al is the wiki content
tmortagne - (16:15): s/al/all/
tmortagne - (16:15): edit in wiki mode
tmortagne - (16:15): to remove the include
tmortagne - (16:15): the second include
silviar - (16:15): it is enough to remove {{include document="platform:Features.Annotations" context="new"/}}?
tmortagne - (16:15): it should not be here anyway
silviar - (16:15): a, ok
silviar - (16:15): :)
silviar - (16:15): thanks
tmortagne - (16:15): even if you want to include another page the include should be in inline content
silviar - (16:16): got it
vmassol - (16:20): CalebJamesDeLisl: what's the status re the invitation manager? is there anything to do to it before the 2.4 final release?
vmassol - (16:20): (haven't tested it yet myself)
CalebJamesDeLisl - (16:21): Add a means to access it (maybe from the user profile)
vmassol - (16:21): is it supposed to be accessible by anyone in the default XE?
vmassol - (16:21): or just admin?
vmassol - (16:22): (I guess I need to try it to know)
vmassol - (16:22): is it supposed to be done and usable right now?
vmassol - (16:22): (except for this accessibility part)
CalebJamesDeLisl - (16:22): Accessable to anyone, to prevent that just disable view to Invitation.WebHome
CalebJamesDeLisl - (16:22): Also XAINVITATION-5
vmassol - (16:23): ok so we could ask silviar and sorin to help us test it?
vmassol - (16:23): silviar: have you or sorin looked at it already
vmassol - (16:23): ?
CalebJamesDeLisl - (16:24): Yup, sometimes the tables get too large but trying to fix that with CSS made it ugly all the time.
vmassol - (16:24): CalebJamesDeLisl: hmm maybe we need caty's help to beautify it then?
CalebJamesDeLisl - (16:25): It's only when the email address is too long. Usually it isn't an issue.
silviar - (16:25): I've only tested it on the incubator so far
silviar - (16:25): Sorin, not yet
CalebJamesDeLisl - (16:26): Incubator is an old version.
vmassol - (16:26): silviar: it should be avail in recent snapshots
vmassol - (16:26): of X 2.4
vmassol - (16:26): *XE
vmassol - (16:26): silviar: do you think sorin or you could plan to test it?
vmassol - (16:27): (fyi XE 2.4 M2 is planned to be released next Monday)
silviar - (16:27): yes, I know about the release date; I'll talk to Sorin to test it, if that's ok with you
vmassol - (16:27): sure
vmassol - (16:27): great
vmassol - (16:27): thanks
silviar - (16:27): np
CalebJamesDeLisl - (16:27): My main goal is to get INVITATION-5 fixed and provide a link in the user profile (XAINVITATION-6)
vmassol - (16:28): CalebJamesDeLisl: re user profile that sounds slightly strange to me
vmassol - (16:28): was this disucssed on the list (I may have missed mails)
lucaa - (16:28): hmm.. guys, what kind of rights do I need to have to have a macro defined in a wiki page recognized as a macro? I have a page with macros invocations and when I log out some of the macros give "unknown macro" errors?
vmassol - (16:28): maybe caty has some ideas on this
lucaa - (16:28): (without ? at the en)
lucaa - (16:28): d
vmassol - (16:28): lucaa: depends on visibility
vmassol - (16:28): (if you're talking about wiki macros)
lucaa - (16:29): yes
CalebJamesDeLisl - (16:29): Somebody suggested it (I forgot who) I have no idea where to put it.
lucaa - (16:30): vmassol: and I assume I need to choose at least current wiki
vmassol - (16:30): depedns what you want to do
lucaa - (16:30): I want it visible to gues
lucaa - (16:30): t
vmassol - (16:30): anyway you need PR for global visibility
vmassol - (16:30): ie in all subwikis
lucaa - (16:31): but how does this work? what does current user mean?
vmassol - (16:31): lucaa: otherwise you just need edit rights
vmassol - (16:31): lucaa:  DefaultWikiMAcroManager.isAllowed()
lucaa - (16:32): vmassol: was that a RTFC?
vmassol - (16:32): yes luke
vmassol - (16:32): if you're curious
vmassol - (16:32): otherwise you just read what I've typed above
vmassol - (16:32): current user means that only your user will see that macro
vmassol - (16:33): you're lucky I was going to RTFM you to http://platform.xwiki.org/xwiki/bin/view/DevGuide/WikiMacroTutorial but it's not documented :)
lucaa - (16:34): assuming that my user saved the macro? created the macro? or what? or it just means "registered user" (as in <> XWiki.Guest)
lucaa - (16:34): also, the fact that it's not visible it means that it just isn't executed? as in I save the page with my user and I cannot view it with other user?
vmassol - (16:34): saved
lucaa - (16:34): (there's a WAFM for that ;) )
lucaa - (16:35): unless current user is some sort of an admin in which case he would see anything, right? regardless of who saved the macro...
vmassol - (16:36): nope
vmassol - (16:36): only the user who saved
vmassol - (16:36): it's for a single user
vmassol - (16:36): private macro feature
lucaa - (16:36): well, there's a bug in there then, I was able to use a macro I didn't save
vmassol - (16:36): with visibility = user?
lucaa - (16:36): yepo
lucaa - (16:37): can you save this page for me please, to change the author
lucaa - (16:37): http://incubator.myxwiki.org/xwiki/bin/view/XWiki/PanelMacro
vmassol - (16:38): done
lucaa - (16:40): I can still see this http://incubator.myxwiki.org/xwiki/bin/view/Sandbox/PanelsMacroTest correctly
lucaa - (16:41): with my global user which has a lot of rights and so on
lucaa - (16:41): if I logout though, I cannot see it anymore
lucaa - (16:41): I get unknown macro exc
tmortagne - (16:41): i get a "Unknown macro: panel"
vmassol - (16:41): looks like a bug then
tmortagne - (16:41): with my farm admin user
tmortagne - (16:42): so it's working well for me
vmassol - (16:42): becuase the way it works is that it's registereed in a map with the currnet user as the key
lucaa - (16:42): with a local little user I get an exception
lucaa - (16:42): then is my user some sort of ... god?
lucaa - (16:42): farm admin
tmortagne - (16:43): did you really refreshed the page ? ;)
lucaa - (16:43): wahahah, good one tmortagne
lucaa - (16:43): I logged in and out a few times so I guess I did...
tmortagne - (16:44): "Unknown macro: panel" with guest user too
tmortagne - (16:44): lucaa:  where is the macro itself ?
lucaa - (16:45): (05:37:51 PM) lucaa: http://incubator.myxwiki.org/xwiki/bin/view/XWiki/PanelMacro
lucaa - (16:45): maybe the're two?
lucaa - (16:45): like a copy of this page?
tmortagne - (16:46): vmassol: doe snot macro works for you ?
tmortagne - (16:46): on http://incubator.myxwiki.org/xwiki/bin/view/Sandbox/PanelsMacroTest
vmassol - (16:46): I saved it
vmassol - (16:46): so i can view it
tmortagne - (16:46): did you tied on http://incubator.myxwiki.org/xwiki/bin/view/Sandbox/PanelsMacroTest ?
tmortagne - (16:46): tried
vmassol - (16:47): yes it works for me and that's normal since I saved that wiki macro
lucaa - (16:47): ok, I'll save it now and we'll see if vmassol still sees it
tmortagne - (16:47): vmassol: i know that's normal... i trying to find why it's working for lucaa
lucaa - (16:47): try again, both
tmortagne - (16:48): "Unknown macro: panel" for me
vmassol - (16:48): I can see it
vmassol - (16:49): looks like some cache issue
lucaa - (16:49): tmortagne, can you save as well so that we all can see it?
lucaa - (16:49): :)
tmortagne - (16:49): vmassol: yes i think when you save the macro it's not removed from the former user CM
vmassol - (16:50): tmortagne: yes
vmassol - (16:50): there's an unregister
vmassol - (16:50): but it's done with the current user probably
vmassol - (16:50): checking
tmortagne - (16:50): yep
tmortagne - (16:50): actually it's not that simple, the unregoster should take care of the old value of the visibility too
vmassol - (16:51): lucaa: so you found a bug
vmassol - (16:52): so basically once you have to right to view the macro you'll get it till the next restart
vmassol - (16:52): s/to right/the right/
vmassol - (16:53): (when current user visibility is used)
lucaa - (16:53): vmassol: it was totally by mistake. I thought I could see / use the macro without ever saving it before (it was initially saved by the author) but I might have remembered bad, since this explanation doesn't apply to that case
vmassol - (16:53): same problem with current wiki too
lucaa - (16:53): s/saved by the author/saved by the creator/
lucaa - (16:56): can you leave that macro on the incubator with current wiki? I kinda need it visible
lucaa - (16:56): thanks
tmortagne - (16:56): vmassol: i don't understand how onEvent even worked for deleted macros
vmassol - (16:57): you mean             } else if (event instanceof DocumentDeleteEvent) {
vmassol - (16:57): doesn'nt work?
tmortagne - (16:57): yes
tmortagne - (16:57): it can't
vmassol - (16:57): we don't send delete events?
tmortagne - (16:57): no that's not it
tmortagne - (16:57): it's calling unregisterMacroInternal with the document reference
tmortagne - (16:58): and unregisterMacroInternal is trying to unregister something that doe snot exists anymore
tmortagne - (16:58): since it onlu has the documen reference
vmassol - (16:58): ah
vmassol - (16:58): :)
tmortagne - (16:58): and not the old version of the document which in in the event datas
vmassol - (16:58): indeed
vmassol - (16:58): we need to add some tests
tmortagne - (16:59): yep i tough we had some but since it's a bad design it loiks like it has bnot been even teste by hand
evalica joined #xwiki at 16:59
tmortagne - (16:59): s/teste/tested/
vmassol - (16:59): tmortagne: you're creating the jira issue for it?
vmassol - (16:59): (please say yes :))
tmortagne - (17:00): let's say ok boss
vmassol - (17:00): coooool
vmassol - (17:00): :)
vmassol - (17:02): CalebJamesDeLisl: this should be removed I believe
vmassol - (17:02): +    @Requirement(role = ScriptMacroValidator.class)
vmassol - (17:02): +    private List<ScriptMacroValidator> validators;
vmassol - (17:03): it makes them static
CalebJamesDeLisl - (17:03): So then how do we get to the validators?
vmassol - (17:03): actually I really need to take the time
vmassol - (17:03): to work on a proxy version for the injections
vmassol - (17:04): so that they are dynamic even when injected with @requiremeent
vmassol - (17:04): right now, it's cm.lookupList
CalebJamesDeLisl - (17:04): Like Guice provider. That's a great idea.
vmassol - (17:04): or like CDI
vmassol - (17:04): (JSR299)
CalebJamesDeLisl - (17:04): Ok, I was looking for LookupList (a class) and couldn't find it.
vmassol - (17:04): they use Instance<MyComponent> myComponent
vmassol - (17:05): and then you do myComponent.get()
vmassol - (17:05): (myComponent field being injected)
vmassol - (17:05): that allows both static and dynamic forms
vmassol - (17:05): I still don't know if we want static in some cases or not
tmortagne - (17:06): CalebJamesDeLisl:
tmortagne - (17:06): @Requirement
tmortagne - (17:06): private ComponentManager componentManager;
CalebJamesDeLisl - (17:06): If we don't want static, how about having a list which is dynamic?
tmortagne - (17:06): to get the CM
CalebJamesDeLisl - (17:06): Boom fanout violation.
vmassol - (17:06): :)
vmassol - (17:07): maybe 21 is too low…. huh huh
vmassol - (17:07): we have some exceptions added in some checkstyle configs and that's not good
CalebJamesDeLisl - (17:07): I like the idea that the list returned is always dynamic.
vmassol - (17:07): I had one or two myself and couldn't find a good idea to reduce the fanout
vmassol - (17:08): CalebJamesDeLisl: it wouldn't be just for list but for any returned type
CalebJamesDeLisl - (17:08): ?
vmassol - (17:08): @Requirement
vmassol - (17:09): private MyComponentRole myComponent;
CalebJamesDeLisl - (17:09): What I mean is when I call a list the way I did, I should get a list which is a "view" of the component registry.
vmassol - (17:10): CalebJamesDeLisl: you need 2 tests IMO
vmassol - (17:10): macroscript3
vmassol - (17:10): you've hijacked a test!
vmassol - (17:10): :)
vmassol - (17:10): the test was about "+.# Validate wiki=false option"
vmassol - (17:10): and now it's about a lot more
florinciu joined #xwiki at 17:11
vmassol - (17:11): I think a separate tests for this feature would be better
jvdrean left at 17:11 (Quit: Leaving.
CalebJamesDeLisl - (17:11): AFAIK no changes were made to unit tests.
vmassol - (17:11): ah no my bad
vmassol - (17:11): you haven't added a test!
vmassol - (17:11): we need one
vmassol - (17:11): to prove that it works
CalebJamesDeLisl - (17:12): r29501
vmassol - (17:12): ah
vmassol - (17:12): no
CalebJamesDeLisl - (17:12): It is an integration test though.
vmassol - (17:12): not ui-tests
vmassol - (17:12): ouch
vmassol - (17:12): bad
vmassol - (17:12): we *awlays* need unit tests
vmassol - (17:12): always always always
vmassol - (17:12): and *sometimes* functional tests
vmassol - (17:12): :)
vmassol - (17:13): why everything?
CalebJamesDeLisl - (17:13): Trying to figure out whether i'm past halfway through this quagmire.
vmassol - (17:13): I think you are
jvdrean joined #xwiki at 17:13
vmassol - (17:13): a unit test should be pretty easy to write
vmassol - (17:13): much more than a functional test
vmassol - (17:14): but yes
vmassol - (17:14): personally I wouldn't have applied the patch
vmassol - (17:14): without a unit test
CalebJamesDeLisl - (17:14): I learned to hate unit tests because xwiki-core is such a rat's nest.
vmassol - (17:14): xwiki-core indeed
abusenius - (17:15): I can write those unit tests, I just didn't know how to fix old ones
CalebJamesDeLisl - (17:15): Great. I have other stuff to do today.
abusenius - (17:16): the problem is that they were testing e.g. if the inner macro is evaluated
abusenius - (17:16): but there are only script macros available, and nested scripts are forbidden now
CalebJamesDeLisl - (17:17): I actually like functional tests because they prove everything works. Unit tests are like an advanced debugging tool IMO.
vmassol - (17:17): CalebJamesDeLisl: not really but we could talk a long time avbout this
vmassol - (17:17): since this is my domain of predilection
vmassol - (17:17): :)
vmassol - (17:18): (unfortunatley we both don't have the time right now)
abusenius - (17:18): but testing that nested scripts fail is easy
CalebJamesDeLisl - (17:18): Ping me when you have some tests.
abusenius - (17:18): ok
evalica left at 17:18 (Read error: Connection reset by peer
bblfish left at 17:19 (Quit: Leaving.
CalebJamesDeLisl - (17:19): lunch time
evalica joined #xwiki at 17:19
vmassol - (17:19): bon appetit
bblfish joined #xwiki at 17:20
KermitTheFragger joined #xwiki at 17:31
arkub joined #xwiki at 17:31
silviar left at 17:37 (Quit: Leaving.
florinciu left at 17:53 (Quit: Leaving.
florinciu joined #xwiki at 18:00
florinciu left at 18:21 (Quit: Leaving.
arkub left at 18:39 (Quit: Leaving
mflorea left at 18:50 (Quit: Leaving.
KermitTheFragger left at 18:52 (Quit: Leaving
evalica left at 19:02 (Ping timeout: 260 seconds
jvdrean left at 19:18 (Quit: Leaving.
lucaa left at 19:21 (Quit: Leaving.
abusenius left at 19:28 (Ping timeout: 276 seconds
abusenius joined #xwiki at 19:33
jfx joined #xwiki at 19:36
tmortagne left at 19:39 (Quit: Leaving.
vmassol left at 19:42 (Quit: Leaving.
mflorea joined #xwiki at 20:03
mflorea left at 20:08 (Quit: Leaving.
nuvolari left at 20:39 (Remote host closed the connection
vmassol joined #xwiki at 20:40
vmassol1 joined #xwiki at 20:44
vmassol1 left at 20:44 (Client Quit
vmassol1 joined #xwiki at 20:46
vmassol left at 20:48 (Ping timeout: 245 seconds
nuvolari joined #xwiki at 20:54
abusenius left at 22:02 (Quit: Konversation terminated!
abusenius joined #xwiki at 22:02
dlindgren left at 22:25 (Quit: Page closed
florinciu joined #xwiki at 23:11
vmassol1 left at 23:15 (Quit: Leaving.
vmassol joined #xwiki at 23:16
vmassol left at 23:29 (Quit: Leaving.
npm left at 23:33 (Quit: Leaving.
npm joined #xwiki at 23:37