IRC Archive for channel #xwiki
Last modified by Vincent Massol on 2012/10/18 19:21
00:03 <+sburjan`> iti dau eu crack
00:25 <rrodriguez> has quit
04:50 <DrLou> has quit
06:51 <mflorea> has joined #xwiki
06:51 <@sdumitriu> Hey mflorea
06:51 <@sdumitriu> You're up early
06:51 <+mflorea> yep
06:51 <@sdumitriu> Can you take a look at the failing tests/
06:52 <+mflorea> I'll look at the failing tests
06:52 <@sdumitriu> ?
06:52 <+mflorea> yep
06:52 <@sdumitriu> Thanks
06:52 <+mflorea> np
06:53 <@sdumitriu> Except the tests, you're OK for the release? Anything else you want to commit?
06:56 <+mflorea> yes, I don't have anything else big to commit (just a few minor code improvements but that should be quick)
07:00 <Denis1> has joined #xwiki
07:00 <Denis> has quit
07:45 <sdumitriu> has quit
08:20 <vmassol> has joined #xwiki
08:40 <Denis1> is now known as <Denis>
08:42 <vmassol> good morning
08:43 <vmassol> we need to fix the still failing functional tests ...
09:05 <vmassol> mflorea: is your last commit why some functional tests were failing?
09:06 <vmassol> (missing XAR)
09:06 <+mflorea> indirectly yes
09:07 <+mflorea> I'm fixing the tests
09:07 <vmassol> what was the issues?
09:08 <vmassol> (just want to make sure that XE works even if there's no XAR)
09:14 <tmortagne> has joined #xwiki
09:14 <sburjan> has joined #xwiki
09:25 <+mflorea> there wasn't any issue. I said "indirectly". Some tests fail because the new sheet system is applied even for old applications. While debugging this I noticed that the SheetClass is missing.
09:46 <vmassol> mflorea: I see you've modified exisitng applications to use the new sheet system
09:47 <vmassol> I hope this wasn't needed to fix the tests
09:47 <vmassol> since old applications still need to work without change for backward compat
09:47 <+mflorea> nop, the last 2 commits are not about using the new sheet system
09:47 <vmassol> did you need to make those changes to have the tests pass?
09:47 <+mflorea> well, you have to make a change for backward compat, but it's small
09:47 <vmassol> argh
09:48 <vmassol> that's a blocker
09:48 <+mflorea> I need those changes for backward compatibility
09:48 <vmassol> because it means no backward compat
09:48 <vmassol> :(
09:49 <vmassol> can you explain a bit more?
09:49 <+mflorea> you have backward compatibility, but not by default. You have to enable it, but simply adding an object of type EditModeClass to your sheets
09:49 <vmassol> I want to be 100% sure any existing app will continue to work
09:49 <vmassol> ok so that's not backwrad compat
09:49 <vmassol> it means that 100% of existing apps will fail
09:49 <vmassol> we cannot release with this
09:50 <vmassol> I'm really sad that this is coming up now one week after the release date since I thought I made it clear we needed 100% backward compat
09:50 <vmassol> :(
09:50 <vmassol> so we need to find another system
09:51 <+mflorea> backward compatibility is implemented, it's not "enabled" by default
09:51 <vmassol> this is NOT backward compat
09:51 <vmassol> and it's not like a switch
09:51 <vmassol> it's for every app
09:51 <vmassol> if it were a config param in the xwiki config file it woudl be ok
09:55 <Enygma`> has joined #xwiki
09:55 <+mflorea> the current solution is the best option. One of the main goals of the new sheet system was to apply sheets automatically. Meaning that you don't have to do anything but add and object of you data and the sheet is automatically detected. This is true for old applications also. So you either complicate the new system by forcing the user to explicitly "call" the sheet (so that is isn't called for old apps) or you force old apps to block the new sheet system, wh
09:58 <vmassol> it's not the problem
09:58 <vmassol> we must absolutely keep backward compat
09:59 <vmassol> this means that any existing app will continue to work without change
09:59 <vmassol> the largest change we can allow is a config flag
09:59 <vmassol> but not having to modify any single app
09:59 <vmassol> btw are you volunterring to change every single app on extensions.xwiki.org?
10:00 <vmassol> + got to the 100s of customer sites already using xwiki
10:00 <vmassol> to change every single app they have
10:00 <vmassol> ?
10:00 <+mflorea> it's not a big change
10:00 <vmassol> so no the current is definitely not the best solution as you say
10:00 <+Denis> mflorea: could not the new sheet system detect an old app, which explicitly call their sheet ?
10:00 <vmassol> I'm a big big ?1
10:01 <vmassol> to release like this
10:01 <vmassol> especially in a 3.2 release ie well into the cycle
10:05 <vmassol> restarting irc bb in 1mn
10:05 <vmassol> back
10:05 <vmassol> (it worked without restarting ;))
10:10 <@cjdelisle> http://www.youtube.com/aclfestival <-- semi-live music (replay of what was live yesterday)
10:11 <vmassol> mflorea: I think this situation could have been avoided if you had sent a proposal/vote mail to the dev list about the need to modify existing apps to make them work. We should always ask opinions for important changes like this one IMO.
10:11 <vmassol> (unless you only realized it now which is a different story, in which case I'm glad I caught it ;))
10:20 <vmassol> guys, seen that we need some more time for the build to stabilize (we still have functional tests failing) + this issue with backward compat + the fact that sergiu still hasn't committed his changes for lucene 3.x, I'd like to propose to postpone M3 to next week (26th) and move RC1 to 3rd of OCtober and final stays for the 10th. WDYT? Should I send a mail?
10:21 <+mflorea> +1
10:21 <vmassol> this means we absolutely need to release on 26 since we'll only have 1 week for RC1
10:21 <vmassol> which means we need to be ready to release around thursday
10:31 <evalica> has joined #xwiki
11:03 <evalica> has quit
11:09 <evalica> has joined #xwiki
11:51 <vmassol> tmortagne: wdyt about my proposal to postpone M3 release above?
11:51 <vmassol> cjdelisle, Denis, all, any input?
11:51 <vmassol> I can send an email but I won't a quick check first here
11:51 <vmassol> s/can/will/
11:51 <vmassol> s/won't/wanted/
11:51 <vmassol> :)
11:52 <vmassol> (my fingers are typing by themselves…)
11:53 <@cjdelisle> I don't have enough information about the specific issue to comment.
11:54 <@cjdelisle> However if we did want to postpone and we were happy to apply a change to c.x.x.XWiki we could fix the problem which is blocking installation in myxwiki.org.
11:56 <@cjdelisle> That change is however a bit dangerous since it is fixing an issue with putting macros into the root namespace so, by definition, there are going to be some uses which it breaks
11:57 <+Denis> vmassol: +1 for me
11:59 <vmassol> ok I'll send a mail
12:22 <mflorea> has quit
13:05 <DrLou> has joined #xwiki
13:07 <mflorea> has joined #xwiki
13:55 <@cjdelisle> mflorea: I read your proposal on the list, are you proposing that when I create a document called XyzClassSheet, now any document with an XyzClass object will magicly change?
13:56 <+mflorea> yes
13:56 <@cjdelisle> Aren't you concerned that it will inhibit people from understanding the tools that they are using when the tools don't seem to make any sense?
13:56 <+mflorea> but my mail doesn't propose this, this is already implemented. The mail was about backward compatibility with current apps
13:57 <@cjdelisle> Was it proposed earlier and I missed it?
13:57 <+mflorea> cjdelisle: it's called convention over configuration
13:57 <+mflorea> and of course you can change the default behavior through configuration, but by default, naming convention is used
13:58 <+mflorea> why would you name a page XyzClassSheet if not to be a sheet for XyzClass?
13:58 <@cjdelisle> The first problem I see is that people will not be able to learn the tools that they are using because the tools are not behaving in a rational manor. When you name things a certain way the toold magicly change behavior.
13:59 <+mflorea> I don't see the part that is not rational
14:00 <@cjdelisle> If you are first learning XWiki, you see a sheet, a class and a document. When you see the document include the sheet and contain the class, it all makes sense. 3 tools, each providing a function.
14:00 <+mflorea> 99% of the time when you have XyzClassSheet you want it to be the sheet for XyzClass, why state the obvious and not do it automatically
14:01 <@cjdelisle> It's "do what I mean" as opposed to "do what I say"
14:01 <@cjdelisle> perl is developed that way
14:01 <@cjdelisle> which is why it makes no sense (at least not to me)
14:01 <+mflorea> exactly, by naming XyzClassSheet you _mean_ it's a sheet for XyzClass
14:02 <@cjdelisle> Well the part about magic filenames aside
14:02 <+mflorea> at an abstract level, there's no different between using the include macro and using a naming convetion. Both are way to specify which is the sheet
14:02 <pturcotte> has quit
14:02 <+mflorea> the naming convention is more natiral
14:02 <+mflorea> natural
14:02 <+mflorea> plus
14:03 <@cjdelisle> have you considered what will happen if I register a user called XWikiUsersSheet?
14:03 <@cjdelisle> am I going to break all of the profiles and/or inject PR script?
14:03 <+mflorea> XWikiUsersSheet already exists, I don't see the problem.
14:03 <+mflorea> I'm not adding new sheets
14:04 <+mflorea> currently XWikiUsersSheet is include in all users, to its the same
14:04 <@cjdelisle> Well there's a natural security issue in the fact that I can look for a class which contains no sheet and create a sheet then look for PR documents which use that class.
14:05 <+mflorea> as I said, you can easily overwrite the "default" sheet
14:05 <+mflorea> and specify another one
14:06 <@cjdelisle> But since XWiki is mostly confined to intranets I don't think security is as much of an issue as the fact that it's magic filenames.
14:07 <+mflorea> do you think maven is magic? it applies the same principle, convention over configuration. You don't have to specify that sources are in src/main/java or that resources are src/main/resources. It's convention that makes your life easier
14:07 <+mflorea> it's a best practice
14:08 <+mflorea> and for XWiki, naming XyzClass and XyzClassSheet is a best practice
14:08 <@cjdelisle> I would liken it more to Microsoft Windows where you can't create a file called COM1 because that's a magic filename.
14:09 <+mflorea> I don't see why? what's "COM1" in my case?
14:09 <+mflorea> what page name can't you use?
14:10 <@cjdelisle> well I am not allowed to create a document called XyzClassSheet if XyzClass exists.
14:10 <+mflorea> why not?
14:10 <+mflorea> how prevents you from doing this?
14:10 <+mflorea> s/how/who
14:10 <@cjdelisle> Because I would be breaking all of the documents which use XyzClass
14:11 <@cjdelisle> It wasn't so long ago that we couldn't create documents with special characters, I kind of see this as a step back toward that.
14:11 <+mflorea> but you can, that's one point, and if you do it, then you 99% want to create a sheet for that clss
14:11 <@cjdelisle> If somebody learns by following instructions, I guess it takes out one step and makes their lives easier
14:12 <@cjdelisle> but people like me learn by understanding the function of the tools which they are using.
14:12 <+mflorea> why is it hard to learn a naming convention?
14:12 <+mflorea> which is a best practice anyway
14:13 <+mflorea> and it's the natural naming
14:13 <@cjdelisle> A naming convention I don't mind, what I mind is having magic things happen when you use that naming convention.
14:13 <+mflorea> that's the convention for
14:13 <+Denis> mflorea: so the sheet document does not require a sheetClass object to be a sheet ?
14:13 <+mflorea> Denis: right, the sheet class is optional, if you want custom things
14:14 <+Denis> woah
14:14 <+mflorea> (like apply the sheet only for a specific action)
14:14 <+mflorea> Denis?
14:14 <+Denis> I am incline to be with Caleb on this
14:14 <+mflorea> why?
14:15 <+Denis> there is nothing in xzyClassSheet that implied it is a sheet
14:15 <+mflorea> there is... it's name
14:15 <+mflorea> and the fact that XyzClass exists, and it's a class
14:15 <+Denis> this is just a name anyone could use for a document without knowing it is writing a sheet at all
14:16 <+Denis> like xyzClass is not implied to be a class
14:17 <+mflorea> why would you put "Class" and "Sheet" in the name? Do you have any _real_ use case?.. I feel we're talking only theoretically here, while in practice 99% of the time, when you create XyzClass it is a class and XyzClassSheet it is a sheet
14:18 <@cjdelisle> I think what it is with me is that telling me to follow certain rules and that when I do it will "just work" is telling me that I am too stupid to understand the tools and how to use them.
14:18 <+mflorea> did you ever created a page XyzClass that wasn't a class?
14:19 <+Denis> Let say I have no XWiki knowledge, my boss use XWiki for an intranet, and I am starting use it for my technical specs, there is chances I will use names like blablaClass for talking about some class, no ?
14:20 <+mflorea> no... Caleb, it means that some people have uses the tools and they have come to the conclusion that 99% we do like this and this has become a good practice and since it's also natural it's good to make it easier for people to create sheets
14:20 <+Denis> no XWiki class but Java Class or what ever
14:20 <+mflorea> Denis, ok, go on
14:20 <+mflorea> question: do you make it a class or not?
14:20 <+mflorea> I suppose not
14:21 <+mflorea> you just create a page named MyJavaClass
14:21 <+Denis> so when you name a document anything, and put a Class in it, you explicitly say you whant a class
14:21 <+mflorea> what next?
14:21 <+mflorea> let's continue with this use case
14:21 <+mflorea> you created a page named MyJavaClass, which isn't a class
14:21 <+mflorea> what do you do next?
14:22 <+Denis> so when you name another document anything, and say explicitely in let say a SheetClass object, that this document is a sheet for your class, then the magic could happen
14:22 <+mflorea> ok, so you also create MyJavaClassSheet (I don't know why if not for a sheet, but let's suppose you do)
14:23 <+mflorea> now, how would the sheet be applied? you have to have an object of type MyJavaClass to a page, but you can't because MyJavaClass is not a class
14:24 <@cjdelisle> I think the basic consept of extensibility is that we build a platform and we don't know how people are going to use it.
14:25 <@cjdelisle> Imagine you're learning XWiki and you happen to be a programmer so you just open up an application and read over it for yourself. How are you ever expected to know that the reason why it works is because of the name of the document?
14:25 <+mflorea> a platform has best practices. They are not enforced (in this case you can bind a different sheet than the one following the naming convention) but you are advised to use them
14:25 <+mflorea> cjdelisle: give me a real use case, step by step
14:25 <+mflorea> let's take the java example
14:26 <+mflorea> tell me the steps
14:26 <@cjdelisle> I don't know of any use case which would cause a bug, I do know that I would be very unhappy and probably drop XWiki on the spot if I was trying to learn it by reading an application only to discover that the application only works because of the names of the documents it is in.
14:27 <+Denis> mflorea: I just says that like xyzClass could be any abcClass or not be class at all, xyzClassSheet could be sheet for abcClass or not be a sheet at all.
14:27 <+mflorea> Denis: you have to have objects attach to a page in order for the sheet to be applied
14:28 <+Denis> if a class is defined, it is likely that some document will have object for that class
14:28 <+mflorea> i.e. XyzDoc is displayed using XyzClassSheet if it has an object of type XyzClass attached
14:30 <+Denis> even if xyzClassSheet is not a sheet, and xyzDoc has other mecanism to display itself
14:30 <+Denis> how do you prevent that ?
14:30 <+mflorea> Denis: if xyzDoc uses include macro then the backward compat is triggered and the sheet is not applied
14:31 <+mflorea> I mean, the sheet is not applied automatically; xyzDoc makes the sheet call
14:31 <+mflorea> by using the include macro
14:32 <+Denis> ok, but you say in your proposal that you want to allow xyzDoc to includes stuffs, including sheets
14:32 <@cjdelisle> now there's more magic based on what the content of the document is?
14:33 <+mflorea> when I say this I'm referring to "new" sheets, i.e. sheets defined with the SheetClasss
14:33 <+Denis> oups, we missed something
14:33 <+Denis> you just says that sheet does not have to contains a sheetClass object, no ?
14:34 <+mflorea> yes
14:34 <+mflorea> it's optional
14:34 <+Denis> so what is this new sheet ?
14:35 <@cjdelisle> is it really that important that the {{include}} be removed from the document?
14:36 <+Denis> Caleb, the issue with the include is that it require a template or some coding to be created
14:36 <+Denis> on that point, I agree that some magic is interresting
14:37 <@cjdelisle> I would rather handle it in script in the wiki (where I can read it) than hide it in oldcore
14:37 <+Denis> but I am not in favor of document becoming magically a sheet for some class just by naming convention
14:37 <@cjdelisle> I learn by reading code, how can I understand what an application is doing if the name of the document causes something to happen?
14:37 <+mflorea> I put new between quotes, it's not really new. What I tried to explain in the mail is that we use to have a SheetClass for specifying the default edit mode (you would use it for say that a doc must be edited in inline mode by default) and I changed the scope of this class, so be used as a sheet descriptor. As a consequence the code in getDefaultEditMode may be confused by a page containing a sheetClass object: did you mean to describe a sheet
14:41 <+mflorea> cjdelisle: re using the document content, the fact that a blog post is not using the document title and document content for its title and content it's clearly a limitation of the XWiki platform IMO
14:43 <+mflorea> plus, we have to separate content from display. The document should hold only data, while the sheet should control the display. The document shouldn't know which sheet is used to display, it shouldn't even know there are sheets. The document is just data.
14:43 <vmassol> for the record I also think that the naming convention isn't good
14:43 <vmassol> it's too magical and I agree about that
14:43 <vmassol> we can tune that a bit later.
14:44 <vmassol> the issue here is that this new feature has been rushed a bit without much time to think about it/use it
14:44 <+Denis> cjdelisle: I learn reading code with goto declaration etc..., and since component are used and injected, I have to use other ways to learn :), on that point this is quite similar
14:45 <vmassol> (it's also very complex now with lots of possibilities to do the same thing)
14:45 <+Denis> but we all agree that naming convention is too magical, I feel that the optionality of the sheet descriptor is the source of the problem
14:45 <vmassol> what I'd propose is to continue the discussion about this in a mail thread and see if we need to change something in 3.3
14:45 <+mflorea> vmassol: wdym? what is complex?
14:46 <vmassol> but that for 3.2 we release it as something new/experimental and mention that we await feedback
14:46 <vmassol> mflorea: the 4-5 possibilities of doing the same thing
14:46 <+mflorea> list them
14:46 <vmassol> attach an object a given class
14:46 <vmassol> attach an object of a given class to the page holding the class
14:46 <+mflorea> wait
14:46 <vmassol> use a name with *ActionSheet
14:46 <+Denis> vmassol: the issue that prevent release is closely related to the magic of it
14:47 <vmassol> use a name with *Sheet
14:47 <vmassol> I like the first 2 options but I don't like the ones based ont he name
14:47 <vmassol> (on the page name that is)
14:47 <+mflorea> wdym by "attach an object of a given class to the page holding the class" I think you're confusing things
14:47 <vmassol> yes I am, there's something but I don't recall exactly
14:48 <vmassol> you can remind me
14:48 <@cjdelisle> re: dependence injection, I agree, dependency injection is a pain since sometimes you need the program to be running in order to follow where things are going. However, with dependency injection you have an annotation and in java, annotations scream out "MAGIC HERE!"
14:48 <+mflorea> you attach an object of type ClassSheetBinding to a class if you want to bing a sheet other than the one determined by naming convevtion
14:48 <@cjdelisle> this proposal is a little more like dependency injection based on the name of the field.
14:49 <vmassol> cjdelisle: exactly
14:49 <vmassol> that's the part I don't like
14:49 <vmassol> the rest is fine
14:49 <@cjdelisle> I want there to be a way for someone like me to read the code and reason with it and understand what it is doing.
14:50 <+mflorea> the code is in SheetDocumentDisplayer..
14:50 <+mflorea> and DefaultSheetManager
14:51 <vmassol> since we have the notion of objects in xwiki
14:51 <vmassol> (ie metadata)
14:51 <@cjdelisle> I open a document to look at it's code, I see {{include}}, I follow the trail, I see code which formats a page and I go back to the document and find an object. It's all clever, it makes sense and I have just learned how objects, classes, and {{include}} work.
14:51 <vmassol> it's a bad practice (antipattern) to use page name
14:51 <vmassol> as anything menaingful
14:51 <+Denis> agreed
14:52 <vmassol> you'd use that in suboptimal systems who dont have way to add extensible metadata
14:52 <+mflorea> cjdelisle: have you read my comment above about content and display separation?..
14:52 <+Denis> but the injection without the include is like component and could be nice
14:52 <@cjdelisle> I did
14:52 <pturcotte> has joined #xwiki
14:52 <+mflorea> vmassol: naming is just the default, you can always overwrite it..
14:53 <+mflorea> it's not like this is the only way
14:53 <vmassol> that's not ht eproblem mflorea
14:53 <vmassol> it's there
14:53 <+Denis> what cause issue is clearly the fact that a sheet become a sheet and moreover a sheet for a given class, just by its name
14:53 <vmassol> so people will use it
14:53 <@cjdelisle> I open a document, it contains nothing, it has an object. If I'm really clever I might go looking for things like the class and bump into the class sheet but where it inevitably ends is me reading the old core and at that point, my evaluation of XWiki would be over.
14:53 <vmassol> btw I talked to jv about this last week and he also mentioned he didn't like at all the page naming convetion
14:54 <vmassol> (last week = last friday)
14:54 <+Denis> define the fact that a document is a sheet for class using objects and that became really better, since document name are not involved
14:55 <+mflorea> so, you all are using this naming convention and you still want to add a SheetClass empty object just to state the obvious..
14:55 <+Denis> you may event use a sheet for multiple class that way (with more instance of the object defining the sheet)
14:55 <+Denis> not empty
14:55 <+Denis> a sheetClass that say for which class is this sheet
14:55 <+mflorea> nop
14:55 <@cjdelisle> IMO the displaying document needs to tell me, the learner, where to look and find the class sheet. Otherwise I open a document and I meet an immediet dead end.
14:56 <+Denis> and that implicitly say this document is a sheet
14:56 <+mflorea> IMO the class should choose the sheet
14:56 <+mflorea> that's how I designed it
14:56 <+Denis> cjdelisle: the data document is just data, it is dead end, opening a mysql database does not tel you how we use it
14:57 <+mflorea> @Denis exactly
14:57 <@cjdelisle> The data document is where I start out.
14:57 <+Denis> you start at the wrong place :)
14:57 <@cjdelisle> That's where everyone will be and they will see data displayed to them and wonder how that works.
14:58 <@cjdelisle> Or you see an error and you want to track down the cause of the error
14:58 <+Denis> ok, let start at document, and see an object in it
14:58 <+Denis> an object of a given class, so look at the class
14:59 <+mflorea> which can be binded to a sheet
14:59 <+Denis> there see (following mflorea preference) that the class is displayed with a given sheet, isn't that what you want ?
14:59 <+mflorea> b/binded/bound
15:00 <@cjdelisle> If you opened the document in edit mode and it said "This document is displayed by [[XyzClassSheet]]" then it would be much easier on someone trying to follow the trail.
15:01 <@cjdelisle> How about instead of using the document name, create a "SheetClass" and when you create a class, you add a SheetClass object to that class document?
15:02 <+mflorea> who said you can't display this info in edit mode, we have a sheet manager that can tell you the sheet
15:03 <@cjdelisle> SheetClass could point to a class sheet document, or (and it would IMO be much cooler) contain the class sheet as a textArea field right in the SheetClass object.
15:04 <@cjdelisle> Then you just have document/object/class
15:05 <vmassol> mflorea: right now we don't have any name convention that's doing things. I definitely think that using the name as metadata information is plain wrong
15:05 <vmassol> in addition it clutters the document name space since you're not free to use any name you wish anymore
15:05 <+mflorea> you're free
15:05 <+Denis> so do we agree that defining clearly which sheet is used to display which class (using object of class sheetClass or whatever) without document name convention will solve all issue including the one you open a thread for ?
15:06 <vmassol> mflorea: can you explain how could both be free and have a convention on the name?
15:06 <vmassol> (I can bet I can find a use case that makes it not free :)
15:06 <vmassol> )
15:07 <+mflorea> shoot
15:07 <vmassol> (after you explain how you're free)
15:07 <vmassol> (I need to know the exact rules first before making up my use case)
15:08 <vmassol> like wanting to name my page: WhateverViewSheet and in that page I have an object of type XX (where XX is the one you've added)
15:08 <+mflorea> because you can name a page XyzClassSheet. If there is already a class XyzClass and for some reason that defies my logic you still want to have the XyzClassSheet page then you simply add and object of type ClassSheetBinding to XyzClass to specify a different sheet
15:08 <vmassol> suddenly I'll get a strange behavior
15:08 <+mflorea> wait
15:09 <+mflorea> I don't understand, what XX type are you referring to?
15:09 <vmassol> you cannot win mflorea since by definition you're basing on a name convention so there'll always be a use case (even if small) that'll cause a problem
15:10 <+mflorea> that's why I have the ClassSheetBinding class to explcitly bind a class to a sheet, if the naming convention is not good for you
15:10 <vmassol> again that's not hte problem
15:10 <vmassol> the explicit binding is good
15:11 <vmassol> the problems is that people in the know will start using the naming convention
15:11 <+mflorea> vmassol: isn't maven using naming conventions?
15:11 <vmassol> well first 100% of people who don't like maven is becaise it's too magical
15:11 <vmassol> and there are a lot of them
15:11 <vmassol> second we're not building a build tool
15:11 <+mflorea> but we're using it..
15:11 <vmassol> so?
15:12 <vmassol> we're even using non open source tools
15:12 <vmassol> even if I believe in OSS
15:12 <vmassol> how does that matter?
15:12 <vmassol> :)
15:12 <+mflorea> so you don't like maven's "magic"?
15:12 <vmassol> there are good points and bad ones
15:12 <vmassol> but even magic is not that magic all over
15:12 <+Denis> mflorea: at least there is a security issue with the creation of xyzClassSheet by anyone, when xyzClass and their object are in use
15:13 <+mflorea> I'm trying to understand why naming convention is good for maven and bad for us
15:13 <vmassol> mflorea: don't confuse things please
15:13 <vmassol> you're talking about apples and oranges
15:13 <vmassol> let's talk about xwiki
15:13 <+mflorea> yes, which we want to make an application platform
15:13 <@cjdelisle> register user named: XWikiRightsSheet hehe
15:13 <vmassol> if you compared xwiki with a labguage java it would be more appropriate
15:14 <vmassol> because they have more points in common than xwiki and maven
15:14 <vmassol> in any case xwiki should be extensible
15:14 <vmassol> but not magical
15:14 <vmassol> we can vote on that
15:14 <vmassol> to make sure we all agree
15:14 <vmassol> it's quite important actually
15:15 <+Denis> mflorea: this not the document xyzClass that make that document defining an xyzClass, and that should be the same for the sheet
15:15 <vmassol> since it's general direction for everything we do
15:15 <+Denis> vmassol: the direction exist already, see my last comment
15:15 <vmassol> Right now the general strategy is simple:
15:15 <vmassol> whenever we want to add a new behavior we add XObjects metadata
15:16 <vmassol> I really don't see why we would invent anything new
15:16 <vmassol> (and I don't see teh need)
15:17 <vmassol> actually we do have a bit of magic already but we want to remove it: user pages have to be in the XWiki space. That's not nice
15:17 <+mflorea> again, if you want explicit class-sheet binding then you have to add an empty sheet object just to mark a sheet
15:17 <@cjdelisle> I was thinking a similar thing: Every time we add new magic, we attach it to a built in class, if you don't want the magic, don't add an object of that class (EG: XWikiRights)
15:18 <vmassol> mflorea: and again the issue is not the explciit binding, it's with people who are going to use the magic
15:18 <vmassol> mflorea: you can see that differnetly:
15:18 <vmassol> in java they refused to do a lot of stuff asked by users
15:18 <vmassol> why?
15:18 <vmassol> because it made the language dangerous
15:18 <vmassol> people who overuse those extra features
15:19 <vmassol> s/who/would/
15:19 <vmassol> and make the language unreadable
15:19 <vmassol> it's not a good thing to popose several ways of doing something and based on some magical stuff
15:19 <vmassol> it's called overengineering if you prefer
15:20 <vmassol> it's asking for trouble, you can be sure people will abuse it
15:20 <@cjdelisle> I have one question about it: What happens if you have a document with multiple objects of the same class and what if you have multiple objects of different classes?
15:20 <JuanDaugherty> has left #xwiki
15:20 <+mflorea> cjdelisle: read the code :)
15:20 <@cjdelisle> ok, -1 until I'm done reading ;)
15:20 <+mflorea> vmassol: I'm not convinced
15:21 <vmassol> I don't know if this has any impact but in the future the model could well allow a page to have several classes
15:21 <vmassol> mflorea: it's the other way around
15:21 <vmassol> you need to convince us it's good
15:21 <vmassol> since you're changing what we're doing
15:21 <+mflorea> well I tried but I obviously failed
15:22 <@cjdelisle> I am about to offer a counterproposal which I think will make everybody happy but I want to understand how you resolve that problem.
15:22 <vmassol> personally I'm fine to release 3.2 with it because we need to release 3.2 but marked experimental and start a discussion thread on the list for 3.3 and remove it if we don't agree about it
15:23 <vmassol> but since it's starting something new (stuff based on page names) it's important we're all comfortable withi t
15:23 <+mflorea> Denis: regarding your use case, it can be prevented if you set the proper rights on the space containing the sheet. The sheet manager looks in the same space as the class. So you need edit rights on the space containing the sheet to be able to create a sheet for that class and mess the pages containing that type of objects
15:23 <+mflorea> s/space containing the sheet/space containing the class
15:23 <vmassol> because if we agree about using name as menaingful then it opens up lots of possibilities for other stuff too
15:24 <vmassol> it would need to be a general rule that we're allowed to use name convnetions to perfom actions
15:24 <+mflorea> vmassol: I'll send a vote. If you don't like it I can drop the code, it's just a few lines
15:24 <vmassol> ok sounds good to me
15:25 <vmassol> actually mflorea I think we hsould do the other way around, you're right: don't add stuff we'ren ot sure about and add it later on if it's really needed
15:25 <vmassol> rather than start with lots of options and remove some after
15:25 <vmassol> it's easier to add than remove
15:25 <vmassol> (I thought it was more than a few lines)
15:25 <vmassol> (cool to know if you could be removed quickly)
15:25 <vmassol> s/if/it/
15:26 <+Denis> mflorea: I really think your idea is well done, but nobody will understand all of it without reading the documentation, and this will cause more confusion than real magic, this precisely where we are now.
15:26 <+mflorea> DefaultSheetManager looks for naming convention if explicit binding it missing. There are just a few lines
15:27 <+Denis> I am +1 to keep explicit binding only for the release
15:29 <@cjdelisle> I think we should introduce a DisplayerClass with viewSheet, editSheet, and inlineSheet fields which can be added to the document which defines the class. It's better contained and the magic is confined to a built in class so you don't get magic unless you instanciate it.
15:30 <@cjdelisle> Also it's one less document that needs to be loaded from the db since the class has to be loaded anyway for putting together the object.
15:30 <+mflorea> @Denis: well, there is a caveat.. some classes are created ("magically" :) ) when XWiki is first run. I can't explicitly map these classes to their sheets (it would have to hard-code the name of the class used for binging in old core). In this case I used a configuration property.
15:31 <+mflorea> s/binging/binding
15:33 <+Denis> mflorea: not sure I get your last point. Isn't the existing code not using the new stuff at all, and therefore should work using simple backward compatibility ?
15:33 <+mflorea> cjdeliste: :) what if I want to apply a sheet to the document defining the class (i.e. ClassSheet). What if I'm using a different action? In the new model you'll be able to have custom actions... I really spent time thinking about the sheet system..
15:35 <@cjdelisle> you mean if the class contains an object of it's own type?
15:35 <+mflorea> Denis: sooner or later we'd have to move to the new system, and then we're gonna it the problem: there are classes created automatically in old core that have to explicitly binded to their sheets
15:35 <@cjdelisle> *class document
15:36 <+Denis> mflorea: and what is the problem with that ?
15:36 <+mflorea> cjdelisle: yes, and also if you want to apply a custom sheet for a document. The system I implemented allows you to apply a custom sheet for a single document
15:37 <@cjdelisle> also shouldn't it only take effect if the document has no content?
15:38 <+mflorea> Denis: ClassSheetBinding is an implementation detail for the DefaultSheetManager. i.e. the default sheet manager uses this class to mark that a class is bound to a sheet. The code in oldcore shouldn't be aware of this and shouldn't hard-code the name of this class
15:39 <@cjdelisle> if you wanted to support as yet unknown actions, you could use an ActionDisplayerClass where it has 2 fields: action and classSheet
15:40 <+mflorea> cjdelisle: the purpose of the sheet is to display the document. Take the blog post example. The blog should _really_ use the document title and document content for the blog post title and content. The sheet displaying the blog post decides what to do with the blog post title and content. In other words the sheet is a function of the document
15:41 <+mflorea> cjdelisle: I have ClassSheetBinding which specifies the sheet and SheetClass which specifies the action, it's already implemented
15:41 <@cjdelisle> ok
15:41 <@cjdelisle> If you don't like the idea of implementing the sheet as an object that's fine but I don't like the idea of magical document names.
15:42 <+mflorea> I understood very well that :)
15:42 <@cjdelisle> heh
15:42 <+Denis> mflorea: you means that the oldcore is unable to create classSheetBinding object ?
15:43 <JuanDaugherty> has joined #xwiki
15:43 <+mflorea> it is able, but by using ClassSheetBinding class it means it will work only with the DefaultSheetManager, which is bad. SheetManager is a component, and you should be able to use a different impl that uses some other classes to mark that a class is bound to a sheet
15:43 <+mflorea> @Denis
15:45 <+mflorea> i.e. ideally only DefaultSheetManager (from java code at least) should know that a sheet is bound to a class using ClassSheetBinding object
15:45 <jvdrean> has joined #xwiki
15:46 <+Denis> mflorea: I understand that, but this is link to the oldcore, a new core would not suffer that
15:46 <+mflorea> sure
15:46 <+Denis> so while the oldcore exist, we have to live with that limitation IMO
15:47 <+mflorea> hmm, I think there is also the issue that ClassSheetBinding is not present when XWiki starts, i.e. before you import the xar, so actually I doubt you can create an object of this type..
15:48 <+Denis> I just wonder, the SheetManager interface should provide ways to define sheet association and create the binding object
15:48 <+Denis> no ?
15:48 <+mflorea> until know the include macro was used, so you could simply write literally "{{include document=\"SomeSheet\" /}}" but know you have to create an object
15:50 <+mflorea> Denis: I added them at one point but I removed them because I didn't implement them for 3.2 release
15:50 <+mflorea> i.e. I added them to the interface
15:50 <+Denis> when them exist, wouldn't the old core be able to use it ?
15:51 <+mflorea> I guess so, but then the DefaultSheetManager would have to create them in the initialization phase (implements Initializable). Right now they are in the sheet
15:52 <+mflorea> s/sheet/xar
15:54 <+Denis> yes and for now they will continue to work using backcompat
15:55 <pturcotte> has quit
15:55 <+mflorea> yes (I'll have to re-add some code I deleted from old core, now that the magic has gone )
15:56 <pturcotte> has joined #xwiki
16:03 <sdumitriu> has joined #xwiki
16:45 <JuanDaugherty> why does workspaces 1.1 rc2 have so much stuff in it?
16:46 <vmassol> JuanDaugherty: yep was going to say that
16:46 <vmassol> now the only person who could answer your question is jerome velociter since I think he's the only one to have worked on it ;)
16:48 <JuanDaugherty> ah.
16:50 <+Denis> mflorea: for your last thread on ML, are you asking for 3.2 or in general ?
16:50 <+mflorea> 3.2
16:51 <+mflorea> note that it's easy to drop steps of the algorithm
16:51 <+mflorea> so don't take into account the time needed to make the adjustments when voting
16:53 <+Denis> yes, its is just that in general I have doubt on put the relation between sheet and class, on the class
16:54 <+Denis> the class is a class, the doc is data, and the sheet is the code, so I would have seen the binding object in the sheet document
16:54 <+mflorea> well :) the reason it exactly why you don't like the magic: someone can create a page XyzClassSheet and thus break your pages. If you define the binding the sheet then anyone can define the sheet
16:55 <+Denis> this is security matters, but it would not be incouscious
16:55 <+mflorea> my initial idea was that you should have edit rights on the class to be able to bind it to a sheet
16:55 <JuanDaugherty> it looks like jvelociter left the xwiki project c. 3.0
16:56 <+tmortagne> JuanDaugherty: he left XWiki SAS company, not XWiki project
16:56 <JuanDaugherty> ah, I guess that distinction isn't clear enough in my mind yet
16:56 <+tmortagne> and this is more recent that 3.0
16:56 <JuanDaugherty> this?
16:56 <+tmortagne> him living XWiki SAS
16:56 <JuanDaugherty> ah
16:58 <+tmortagne> JuanDaugherty: you could think of it as XWiki SAS having lots of XWiki project contributors in its staff but that's pretty much all, some XWiki project committers are not XWiki SAS employees
16:59 <JuanDaugherty> got it
16:59 <+tmortagne> (and also providing server for xwiki.org)
17:00 <vmassol> JuanDaugherty: you could also read this past email: http://markmail.org/thread/4omxwpung2todjqf
17:00 <vmassol> although the links are probably not correct anymore....
17:01 <vmassol> this one is still valid: http://massol.myxwiki.org/xwiki/bin/view/Blog/XWikiSASAndOpenSource
17:01 <+mflorea> Denis: also, putting the binding in the sheet document could make it more expensive (?) to find the sheet because you have to query the db for all sheets, where "class" prop points to your class.
17:01 <JuanDaugherty> lol 12.5 comitters
17:01 <+tmortagne> :)
17:02 <vmassol> and more here too: http://www.xwiki.com/xwiki/bin/view/Community/OpenSource
17:02 <vmassol> hehe
17:02 <vmassol> don't remember who was the half, probably guillaume ;)
17:03 <+Denis> mflorea: these (rights/perfs) are implementation matter, and the reason for my doubts
17:03 <JuanDaugherty> Dubost is no longer involved?
17:08 <vmassol> he's still a committer
17:08 <vmassol> not very active
17:08 <vmassol> a few commiters every 4-5 months
17:08 <vmassol> s/commiters/commits/
17:08 <vmassol> he's mostly busy running the xwiki sas company
17:08 <JuanDaugherty> i c. He appears to be part of the same venture as jvelociter
17:09 <JuanDaugherty> ie. "winesquare"
17:09 <vmassol> if by venture you mean that they both are working for XWiki SAS then yes
17:09 <vmassol> ah no
17:09 <vmassol> winesquare is the new project from jerome
17:09 <vmassol> ludovic isn't involved
17:09 <vmassol> that's why he left xwiki sas, to start his own startup around this project
17:10 <JuanDaugherty> it says he is on their site
17:10 <vmassol> (winesquare is basedon the xwiki platform btw ;))
17:10 <vmassol> really?
17:10 <vmassol> never checked his web site actually
17:10 <vmassol> looking
17:10 <vmassol> link?
17:10 <JuanDaugherty> no, my bad on their site they have a FB thing which
17:10 <vmassol> right
17:10 <JuanDaugherty> has him having given a like
17:11 <JuanDaugherty> .
17:11 <vmassol> yep
17:11 <vmassol> and there's me now too
17:11 <vmassol> :)
17:11 <vmassol> (just gave a "like")
17:13 <evalica> has quit
17:16 <JuanDaugherty> i see you have been working on workspaces design ( http://dev.xwiki.org/xwiki/bin/view/Design/Workspaces ). Is there anything I should be cognizant of in current stable or upcoming 3.2 on this?
17:26 <vmassol> JuanDaugherty: you shouldn't use workspaces
17:26 <vmassol> it's been retired as you know
17:26 <vmassol> and we've integrated several of its features in XE
17:26 <vmassol> (and no I haven't worked on the design of workspaces)
17:27 <JuanDaugherty> I meant the concept with the URL I just gave, not jvelociter's project
17:27 <JuanDaugherty> besides it's not being supported, why shouldn't I use it?
17:27 <JuanDaugherty> *its
17:28 <vmassol> you can of course but don't expect any support for it. I have for ex no clue that it can even start up or work
17:29 <Enygma`> has quit
17:29 <jvdrean> has quit
17:30 <JuanDaugherty> yeah, it doesn't look well formed which is unfortunate since as your design salient indicates, there is pressing functionality there that one might want to use
17:30 <JuanDaugherty> s/formed/packaged, presented, whatever/
17:30 <jvdrean> has joined #xwiki
17:31 <vmassol> JuanDaugherty: if youhave a need you should talk about it
17:31 <vmassol> maybe it's already covered by an XE extension
17:31 <JuanDaugherty> no I don't think so
17:32 <vmassol> hmm unless you're talking about the new workspaces
17:33 <vmassol> this one http://dev.xwiki.org/xwiki/bin/view/Design/Workspaces has nothing to do with XWiki Workspaces done by Jerome Velociter
17:33 <vmassol> it's a new project and will be released as an XE extension very soon
17:34 <JuanDaugherty> that does appear to be the same URL I mentioned parenthetically above
17:34 <JuanDaugherty> very soon means after 3.2?
17:35 <vmassol> yes it is but I thought you were continuing on the discussion about the retired xwiki workspaces (XWS)
17:35 <vmassol> yes probably soon after 3.2
17:35 <JuanDaugherty> why would I do that?
17:35 <vmassol> sorry got to go work a bit
17:35 <JuanDaugherty> k, great, thx
17:35 <vmassol> ttyl
17:50 <abusenius> has joined #xwiki
17:56 <vmassol> has quit
17:59 <vmassol> has joined #xwiki
17:59 <sburjan> has quit
18:02 <vmassol> has quit
18:21 <vmassol> has joined #xwiki
18:50 <mflorea> has quit
19:51 <pturcotte> has quit
19:53 <pturcotte> has joined #xwiki
20:12 <Enygma`> has joined #xwiki
20:20 <+sburjan`> cjdelisle: around ?
20:23 <@cjdelisle> I am but not for much longer
20:23 <@cjdelisle> what's up?
20:23 <+sburjan`> just one question
20:23 <+sburjan`> regarding the EM permanent directory vote
20:24 <+sburjan`> option #2 will mean that if you want to run the xwiki as another user, you will have to move t he ~./xwiki dir to the new user's homedir, right ?
20:24 <@cjdelisle> correct.
20:25 <+sburjan`> ok. just wanted to know it for sure
20:25 <@cjdelisle> on a production machine it should really always run as "tomcat" though
20:25 <+sburjan`> yepp. or www (httpd)
20:25 <@cjdelisle> yup
20:50 <tmortagne> has quit
21:21 <vmassol> has quit
21:21 <mflorea> has joined #xwiki
23:12 <pturcotte> has quit
23:28 <Enygma`> has quit
23:39 <abusenius> has quit
23:54 <mflorea> has quit
00:25 <rrodriguez> has quit
04:50 <DrLou> has quit
06:51 <mflorea> has joined #xwiki
06:51 <@sdumitriu> Hey mflorea
06:51 <@sdumitriu> You're up early
06:51 <+mflorea> yep
06:51 <@sdumitriu> Can you take a look at the failing tests/
06:52 <+mflorea> I'll look at the failing tests
06:52 <@sdumitriu> ?
06:52 <+mflorea> yep
06:52 <@sdumitriu> Thanks
06:52 <+mflorea> np
06:53 <@sdumitriu> Except the tests, you're OK for the release? Anything else you want to commit?
06:56 <+mflorea> yes, I don't have anything else big to commit (just a few minor code improvements but that should be quick)
07:00 <Denis1> has joined #xwiki
07:00 <Denis> has quit
07:45 <sdumitriu> has quit
08:20 <vmassol> has joined #xwiki
08:40 <Denis1> is now known as <Denis>
08:42 <vmassol> good morning
08:43 <vmassol> we need to fix the still failing functional tests ...
09:05 <vmassol> mflorea: is your last commit why some functional tests were failing?
09:06 <vmassol> (missing XAR)
09:06 <+mflorea> indirectly yes
09:07 <+mflorea> I'm fixing the tests
09:07 <vmassol> what was the issues?
09:08 <vmassol> (just want to make sure that XE works even if there's no XAR)
09:14 <tmortagne> has joined #xwiki
09:14 <sburjan> has joined #xwiki
09:25 <+mflorea> there wasn't any issue. I said "indirectly". Some tests fail because the new sheet system is applied even for old applications. While debugging this I noticed that the SheetClass is missing.
09:46 <vmassol> mflorea: I see you've modified exisitng applications to use the new sheet system
09:47 <vmassol> I hope this wasn't needed to fix the tests
09:47 <vmassol> since old applications still need to work without change for backward compat
09:47 <+mflorea> nop, the last 2 commits are not about using the new sheet system
09:47 <vmassol> did you need to make those changes to have the tests pass?
09:47 <+mflorea> well, you have to make a change for backward compat, but it's small
09:47 <vmassol> argh
09:48 <vmassol> that's a blocker
09:48 <+mflorea> I need those changes for backward compatibility
09:48 <vmassol> because it means no backward compat
09:48 <vmassol> :(
09:49 <vmassol> can you explain a bit more?
09:49 <+mflorea> you have backward compatibility, but not by default. You have to enable it, but simply adding an object of type EditModeClass to your sheets
09:49 <vmassol> I want to be 100% sure any existing app will continue to work
09:49 <vmassol> ok so that's not backwrad compat
09:49 <vmassol> it means that 100% of existing apps will fail
09:49 <vmassol> we cannot release with this
09:50 <vmassol> I'm really sad that this is coming up now one week after the release date since I thought I made it clear we needed 100% backward compat
09:50 <vmassol> :(
09:50 <vmassol> so we need to find another system
09:51 <+mflorea> backward compatibility is implemented, it's not "enabled" by default
09:51 <vmassol> this is NOT backward compat
09:51 <vmassol> and it's not like a switch
09:51 <vmassol> it's for every app
09:51 <vmassol> if it were a config param in the xwiki config file it woudl be ok
09:55 <Enygma`> has joined #xwiki
09:55 <+mflorea> the current solution is the best option. One of the main goals of the new sheet system was to apply sheets automatically. Meaning that you don't have to do anything but add and object of you data and the sheet is automatically detected. This is true for old applications also. So you either complicate the new system by forcing the user to explicitly "call" the sheet (so that is isn't called for old apps) or you force old apps to block the new sheet system, wh
09:58 <vmassol> it's not the problem
09:58 <vmassol> we must absolutely keep backward compat
09:59 <vmassol> this means that any existing app will continue to work without change
09:59 <vmassol> the largest change we can allow is a config flag
09:59 <vmassol> but not having to modify any single app
09:59 <vmassol> btw are you volunterring to change every single app on extensions.xwiki.org?
10:00 <vmassol> + got to the 100s of customer sites already using xwiki
10:00 <vmassol> to change every single app they have
10:00 <vmassol> ?
10:00 <+mflorea> it's not a big change
10:00 <vmassol> so no the current is definitely not the best solution as you say
10:00 <+Denis> mflorea: could not the new sheet system detect an old app, which explicitly call their sheet ?
10:00 <vmassol> I'm a big big ?1
10:01 <vmassol> to release like this
10:01 <vmassol> especially in a 3.2 release ie well into the cycle
10:05 <vmassol> restarting irc bb in 1mn
10:05 <vmassol> back
10:05 <vmassol> (it worked without restarting ;))
10:10 <@cjdelisle> http://www.youtube.com/aclfestival <-- semi-live music (replay of what was live yesterday)
10:11 <vmassol> mflorea: I think this situation could have been avoided if you had sent a proposal/vote mail to the dev list about the need to modify existing apps to make them work. We should always ask opinions for important changes like this one IMO.
10:11 <vmassol> (unless you only realized it now which is a different story, in which case I'm glad I caught it ;))
10:20 <vmassol> guys, seen that we need some more time for the build to stabilize (we still have functional tests failing) + this issue with backward compat + the fact that sergiu still hasn't committed his changes for lucene 3.x, I'd like to propose to postpone M3 to next week (26th) and move RC1 to 3rd of OCtober and final stays for the 10th. WDYT? Should I send a mail?
10:21 <+mflorea> +1
10:21 <vmassol> this means we absolutely need to release on 26 since we'll only have 1 week for RC1
10:21 <vmassol> which means we need to be ready to release around thursday
10:31 <evalica> has joined #xwiki
11:03 <evalica> has quit
11:09 <evalica> has joined #xwiki
11:51 <vmassol> tmortagne: wdyt about my proposal to postpone M3 release above?
11:51 <vmassol> cjdelisle, Denis, all, any input?
11:51 <vmassol> I can send an email but I won't a quick check first here
11:51 <vmassol> s/can/will/
11:51 <vmassol> s/won't/wanted/
11:51 <vmassol> :)
11:52 <vmassol> (my fingers are typing by themselves…)
11:53 <@cjdelisle> I don't have enough information about the specific issue to comment.
11:54 <@cjdelisle> However if we did want to postpone and we were happy to apply a change to c.x.x.XWiki we could fix the problem which is blocking installation in myxwiki.org.
11:56 <@cjdelisle> That change is however a bit dangerous since it is fixing an issue with putting macros into the root namespace so, by definition, there are going to be some uses which it breaks
11:57 <+Denis> vmassol: +1 for me
11:59 <vmassol> ok I'll send a mail
12:22 <mflorea> has quit
13:05 <DrLou> has joined #xwiki
13:07 <mflorea> has joined #xwiki
13:55 <@cjdelisle> mflorea: I read your proposal on the list, are you proposing that when I create a document called XyzClassSheet, now any document with an XyzClass object will magicly change?
13:56 <+mflorea> yes
13:56 <@cjdelisle> Aren't you concerned that it will inhibit people from understanding the tools that they are using when the tools don't seem to make any sense?
13:56 <+mflorea> but my mail doesn't propose this, this is already implemented. The mail was about backward compatibility with current apps
13:57 <@cjdelisle> Was it proposed earlier and I missed it?
13:57 <+mflorea> cjdelisle: it's called convention over configuration
13:57 <+mflorea> and of course you can change the default behavior through configuration, but by default, naming convention is used
13:58 <+mflorea> why would you name a page XyzClassSheet if not to be a sheet for XyzClass?
13:58 <@cjdelisle> The first problem I see is that people will not be able to learn the tools that they are using because the tools are not behaving in a rational manor. When you name things a certain way the toold magicly change behavior.
13:59 <+mflorea> I don't see the part that is not rational
14:00 <@cjdelisle> If you are first learning XWiki, you see a sheet, a class and a document. When you see the document include the sheet and contain the class, it all makes sense. 3 tools, each providing a function.
14:00 <+mflorea> 99% of the time when you have XyzClassSheet you want it to be the sheet for XyzClass, why state the obvious and not do it automatically
14:01 <@cjdelisle> It's "do what I mean" as opposed to "do what I say"
14:01 <@cjdelisle> perl is developed that way
14:01 <@cjdelisle> which is why it makes no sense (at least not to me)
14:01 <+mflorea> exactly, by naming XyzClassSheet you _mean_ it's a sheet for XyzClass
14:02 <@cjdelisle> Well the part about magic filenames aside
14:02 <+mflorea> at an abstract level, there's no different between using the include macro and using a naming convetion. Both are way to specify which is the sheet
14:02 <pturcotte> has quit
14:02 <+mflorea> the naming convention is more natiral
14:02 <+mflorea> natural
14:02 <+mflorea> plus
14:03 <@cjdelisle> have you considered what will happen if I register a user called XWikiUsersSheet?
14:03 <@cjdelisle> am I going to break all of the profiles and/or inject PR script?
14:03 <+mflorea> XWikiUsersSheet already exists, I don't see the problem.
14:03 <+mflorea> I'm not adding new sheets
14:04 <+mflorea> currently XWikiUsersSheet is include in all users, to its the same
14:04 <@cjdelisle> Well there's a natural security issue in the fact that I can look for a class which contains no sheet and create a sheet then look for PR documents which use that class.
14:05 <+mflorea> as I said, you can easily overwrite the "default" sheet
14:05 <+mflorea> and specify another one
14:06 <@cjdelisle> But since XWiki is mostly confined to intranets I don't think security is as much of an issue as the fact that it's magic filenames.
14:07 <+mflorea> do you think maven is magic? it applies the same principle, convention over configuration. You don't have to specify that sources are in src/main/java or that resources are src/main/resources. It's convention that makes your life easier
14:07 <+mflorea> it's a best practice
14:08 <+mflorea> and for XWiki, naming XyzClass and XyzClassSheet is a best practice
14:08 <@cjdelisle> I would liken it more to Microsoft Windows where you can't create a file called COM1 because that's a magic filename.
14:09 <+mflorea> I don't see why? what's "COM1" in my case?
14:09 <+mflorea> what page name can't you use?
14:10 <@cjdelisle> well I am not allowed to create a document called XyzClassSheet if XyzClass exists.
14:10 <+mflorea> why not?
14:10 <+mflorea> how prevents you from doing this?
14:10 <+mflorea> s/how/who
14:10 <@cjdelisle> Because I would be breaking all of the documents which use XyzClass
14:11 <@cjdelisle> It wasn't so long ago that we couldn't create documents with special characters, I kind of see this as a step back toward that.
14:11 <+mflorea> but you can, that's one point, and if you do it, then you 99% want to create a sheet for that clss
14:11 <@cjdelisle> If somebody learns by following instructions, I guess it takes out one step and makes their lives easier
14:12 <@cjdelisle> but people like me learn by understanding the function of the tools which they are using.
14:12 <+mflorea> why is it hard to learn a naming convention?
14:12 <+mflorea> which is a best practice anyway
14:13 <+mflorea> and it's the natural naming
14:13 <@cjdelisle> A naming convention I don't mind, what I mind is having magic things happen when you use that naming convention.
14:13 <+mflorea> that's the convention for
14:13 <+Denis> mflorea: so the sheet document does not require a sheetClass object to be a sheet ?
14:13 <+mflorea> Denis: right, the sheet class is optional, if you want custom things
14:14 <+Denis> woah
14:14 <+mflorea> (like apply the sheet only for a specific action)
14:14 <+mflorea> Denis?
14:14 <+Denis> I am incline to be with Caleb on this
14:14 <+mflorea> why?
14:15 <+Denis> there is nothing in xzyClassSheet that implied it is a sheet
14:15 <+mflorea> there is... it's name
14:15 <+mflorea> and the fact that XyzClass exists, and it's a class
14:15 <+Denis> this is just a name anyone could use for a document without knowing it is writing a sheet at all
14:16 <+Denis> like xyzClass is not implied to be a class
14:17 <+mflorea> why would you put "Class" and "Sheet" in the name? Do you have any _real_ use case?.. I feel we're talking only theoretically here, while in practice 99% of the time, when you create XyzClass it is a class and XyzClassSheet it is a sheet
14:18 <@cjdelisle> I think what it is with me is that telling me to follow certain rules and that when I do it will "just work" is telling me that I am too stupid to understand the tools and how to use them.
14:18 <+mflorea> did you ever created a page XyzClass that wasn't a class?
14:19 <+Denis> Let say I have no XWiki knowledge, my boss use XWiki for an intranet, and I am starting use it for my technical specs, there is chances I will use names like blablaClass for talking about some class, no ?
14:20 <+mflorea> no... Caleb, it means that some people have uses the tools and they have come to the conclusion that 99% we do like this and this has become a good practice and since it's also natural it's good to make it easier for people to create sheets
14:20 <+Denis> no XWiki class but Java Class or what ever
14:20 <+mflorea> Denis, ok, go on
14:20 <+mflorea> question: do you make it a class or not?
14:20 <+mflorea> I suppose not
14:21 <+mflorea> you just create a page named MyJavaClass
14:21 <+Denis> so when you name a document anything, and put a Class in it, you explicitly say you whant a class
14:21 <+mflorea> what next?
14:21 <+mflorea> let's continue with this use case
14:21 <+mflorea> you created a page named MyJavaClass, which isn't a class
14:21 <+mflorea> what do you do next?
14:22 <+Denis> so when you name another document anything, and say explicitely in let say a SheetClass object, that this document is a sheet for your class, then the magic could happen
14:22 <+mflorea> ok, so you also create MyJavaClassSheet (I don't know why if not for a sheet, but let's suppose you do)
14:23 <+mflorea> now, how would the sheet be applied? you have to have an object of type MyJavaClass to a page, but you can't because MyJavaClass is not a class
14:24 <@cjdelisle> I think the basic consept of extensibility is that we build a platform and we don't know how people are going to use it.
14:25 <@cjdelisle> Imagine you're learning XWiki and you happen to be a programmer so you just open up an application and read over it for yourself. How are you ever expected to know that the reason why it works is because of the name of the document?
14:25 <+mflorea> a platform has best practices. They are not enforced (in this case you can bind a different sheet than the one following the naming convention) but you are advised to use them
14:25 <+mflorea> cjdelisle: give me a real use case, step by step
14:25 <+mflorea> let's take the java example
14:26 <+mflorea> tell me the steps
14:26 <@cjdelisle> I don't know of any use case which would cause a bug, I do know that I would be very unhappy and probably drop XWiki on the spot if I was trying to learn it by reading an application only to discover that the application only works because of the names of the documents it is in.
14:27 <+Denis> mflorea: I just says that like xyzClass could be any abcClass or not be class at all, xyzClassSheet could be sheet for abcClass or not be a sheet at all.
14:27 <+mflorea> Denis: you have to have objects attach to a page in order for the sheet to be applied
14:28 <+Denis> if a class is defined, it is likely that some document will have object for that class
14:28 <+mflorea> i.e. XyzDoc is displayed using XyzClassSheet if it has an object of type XyzClass attached
14:30 <+Denis> even if xyzClassSheet is not a sheet, and xyzDoc has other mecanism to display itself
14:30 <+Denis> how do you prevent that ?
14:30 <+mflorea> Denis: if xyzDoc uses include macro then the backward compat is triggered and the sheet is not applied
14:31 <+mflorea> I mean, the sheet is not applied automatically; xyzDoc makes the sheet call
14:31 <+mflorea> by using the include macro
14:32 <+Denis> ok, but you say in your proposal that you want to allow xyzDoc to includes stuffs, including sheets
14:32 <@cjdelisle> now there's more magic based on what the content of the document is?
14:33 <+mflorea> when I say this I'm referring to "new" sheets, i.e. sheets defined with the SheetClasss
14:33 <+Denis> oups, we missed something
14:33 <+Denis> you just says that sheet does not have to contains a sheetClass object, no ?
14:34 <+mflorea> yes
14:34 <+mflorea> it's optional
14:34 <+Denis> so what is this new sheet ?
14:35 <@cjdelisle> is it really that important that the {{include}} be removed from the document?
14:36 <+Denis> Caleb, the issue with the include is that it require a template or some coding to be created
14:36 <+Denis> on that point, I agree that some magic is interresting
14:37 <@cjdelisle> I would rather handle it in script in the wiki (where I can read it) than hide it in oldcore
14:37 <+Denis> but I am not in favor of document becoming magically a sheet for some class just by naming convention
14:37 <@cjdelisle> I learn by reading code, how can I understand what an application is doing if the name of the document causes something to happen?
14:37 <+mflorea> I put new between quotes, it's not really new. What I tried to explain in the mail is that we use to have a SheetClass for specifying the default edit mode (you would use it for say that a doc must be edited in inline mode by default) and I changed the scope of this class, so be used as a sheet descriptor. As a consequence the code in getDefaultEditMode may be confused by a page containing a sheetClass object: did you mean to describe a sheet
14:41 <+mflorea> cjdelisle: re using the document content, the fact that a blog post is not using the document title and document content for its title and content it's clearly a limitation of the XWiki platform IMO
14:43 <+mflorea> plus, we have to separate content from display. The document should hold only data, while the sheet should control the display. The document shouldn't know which sheet is used to display, it shouldn't even know there are sheets. The document is just data.
14:43 <vmassol> for the record I also think that the naming convention isn't good
14:43 <vmassol> it's too magical and I agree about that
14:43 <vmassol> we can tune that a bit later.
14:44 <vmassol> the issue here is that this new feature has been rushed a bit without much time to think about it/use it
14:44 <+Denis> cjdelisle: I learn reading code with goto declaration etc..., and since component are used and injected, I have to use other ways to learn :), on that point this is quite similar
14:45 <vmassol> (it's also very complex now with lots of possibilities to do the same thing)
14:45 <+Denis> but we all agree that naming convention is too magical, I feel that the optionality of the sheet descriptor is the source of the problem
14:45 <vmassol> what I'd propose is to continue the discussion about this in a mail thread and see if we need to change something in 3.3
14:45 <+mflorea> vmassol: wdym? what is complex?
14:46 <vmassol> but that for 3.2 we release it as something new/experimental and mention that we await feedback
14:46 <vmassol> mflorea: the 4-5 possibilities of doing the same thing
14:46 <+mflorea> list them
14:46 <vmassol> attach an object a given class
14:46 <vmassol> attach an object of a given class to the page holding the class
14:46 <+mflorea> wait
14:46 <vmassol> use a name with *ActionSheet
14:46 <+Denis> vmassol: the issue that prevent release is closely related to the magic of it
14:47 <vmassol> use a name with *Sheet
14:47 <vmassol> I like the first 2 options but I don't like the ones based ont he name
14:47 <vmassol> (on the page name that is)
14:47 <+mflorea> wdym by "attach an object of a given class to the page holding the class" I think you're confusing things
14:47 <vmassol> yes I am, there's something but I don't recall exactly
14:48 <vmassol> you can remind me
14:48 <@cjdelisle> re: dependence injection, I agree, dependency injection is a pain since sometimes you need the program to be running in order to follow where things are going. However, with dependency injection you have an annotation and in java, annotations scream out "MAGIC HERE!"
14:48 <+mflorea> you attach an object of type ClassSheetBinding to a class if you want to bing a sheet other than the one determined by naming convevtion
14:48 <@cjdelisle> this proposal is a little more like dependency injection based on the name of the field.
14:49 <vmassol> cjdelisle: exactly
14:49 <vmassol> that's the part I don't like
14:49 <vmassol> the rest is fine
14:49 <@cjdelisle> I want there to be a way for someone like me to read the code and reason with it and understand what it is doing.
14:50 <+mflorea> the code is in SheetDocumentDisplayer..
14:50 <+mflorea> and DefaultSheetManager
14:51 <vmassol> since we have the notion of objects in xwiki
14:51 <vmassol> (ie metadata)
14:51 <@cjdelisle> I open a document to look at it's code, I see {{include}}, I follow the trail, I see code which formats a page and I go back to the document and find an object. It's all clever, it makes sense and I have just learned how objects, classes, and {{include}} work.
14:51 <vmassol> it's a bad practice (antipattern) to use page name
14:51 <vmassol> as anything menaingful
14:51 <+Denis> agreed
14:52 <vmassol> you'd use that in suboptimal systems who dont have way to add extensible metadata
14:52 <+mflorea> cjdelisle: have you read my comment above about content and display separation?..
14:52 <+Denis> but the injection without the include is like component and could be nice
14:52 <@cjdelisle> I did
14:52 <pturcotte> has joined #xwiki
14:52 <+mflorea> vmassol: naming is just the default, you can always overwrite it..
14:53 <+mflorea> it's not like this is the only way
14:53 <vmassol> that's not ht eproblem mflorea
14:53 <vmassol> it's there
14:53 <+Denis> what cause issue is clearly the fact that a sheet become a sheet and moreover a sheet for a given class, just by its name
14:53 <vmassol> so people will use it
14:53 <@cjdelisle> I open a document, it contains nothing, it has an object. If I'm really clever I might go looking for things like the class and bump into the class sheet but where it inevitably ends is me reading the old core and at that point, my evaluation of XWiki would be over.
14:53 <vmassol> btw I talked to jv about this last week and he also mentioned he didn't like at all the page naming convetion
14:54 <vmassol> (last week = last friday)
14:54 <+Denis> define the fact that a document is a sheet for class using objects and that became really better, since document name are not involved
14:55 <+mflorea> so, you all are using this naming convention and you still want to add a SheetClass empty object just to state the obvious..
14:55 <+Denis> you may event use a sheet for multiple class that way (with more instance of the object defining the sheet)
14:55 <+Denis> not empty
14:55 <+Denis> a sheetClass that say for which class is this sheet
14:55 <+mflorea> nop
14:55 <@cjdelisle> IMO the displaying document needs to tell me, the learner, where to look and find the class sheet. Otherwise I open a document and I meet an immediet dead end.
14:56 <+Denis> and that implicitly say this document is a sheet
14:56 <+mflorea> IMO the class should choose the sheet
14:56 <+mflorea> that's how I designed it
14:56 <+Denis> cjdelisle: the data document is just data, it is dead end, opening a mysql database does not tel you how we use it
14:57 <+mflorea> @Denis exactly
14:57 <@cjdelisle> The data document is where I start out.
14:57 <+Denis> you start at the wrong place :)
14:57 <@cjdelisle> That's where everyone will be and they will see data displayed to them and wonder how that works.
14:58 <@cjdelisle> Or you see an error and you want to track down the cause of the error
14:58 <+Denis> ok, let start at document, and see an object in it
14:58 <+Denis> an object of a given class, so look at the class
14:59 <+mflorea> which can be binded to a sheet
14:59 <+Denis> there see (following mflorea preference) that the class is displayed with a given sheet, isn't that what you want ?
14:59 <+mflorea> b/binded/bound
15:00 <@cjdelisle> If you opened the document in edit mode and it said "This document is displayed by [[XyzClassSheet]]" then it would be much easier on someone trying to follow the trail.
15:01 <@cjdelisle> How about instead of using the document name, create a "SheetClass" and when you create a class, you add a SheetClass object to that class document?
15:02 <+mflorea> who said you can't display this info in edit mode, we have a sheet manager that can tell you the sheet
15:03 <@cjdelisle> SheetClass could point to a class sheet document, or (and it would IMO be much cooler) contain the class sheet as a textArea field right in the SheetClass object.
15:04 <@cjdelisle> Then you just have document/object/class
15:05 <vmassol> mflorea: right now we don't have any name convention that's doing things. I definitely think that using the name as metadata information is plain wrong
15:05 <vmassol> in addition it clutters the document name space since you're not free to use any name you wish anymore
15:05 <+mflorea> you're free
15:05 <+Denis> so do we agree that defining clearly which sheet is used to display which class (using object of class sheetClass or whatever) without document name convention will solve all issue including the one you open a thread for ?
15:06 <vmassol> mflorea: can you explain how could both be free and have a convention on the name?
15:06 <vmassol> (I can bet I can find a use case that makes it not free :)
15:06 <vmassol> )
15:07 <+mflorea> shoot
15:07 <vmassol> (after you explain how you're free)
15:07 <vmassol> (I need to know the exact rules first before making up my use case)
15:08 <vmassol> like wanting to name my page: WhateverViewSheet and in that page I have an object of type XX (where XX is the one you've added)
15:08 <+mflorea> because you can name a page XyzClassSheet. If there is already a class XyzClass and for some reason that defies my logic you still want to have the XyzClassSheet page then you simply add and object of type ClassSheetBinding to XyzClass to specify a different sheet
15:08 <vmassol> suddenly I'll get a strange behavior
15:08 <+mflorea> wait
15:09 <+mflorea> I don't understand, what XX type are you referring to?
15:09 <vmassol> you cannot win mflorea since by definition you're basing on a name convention so there'll always be a use case (even if small) that'll cause a problem
15:10 <+mflorea> that's why I have the ClassSheetBinding class to explcitly bind a class to a sheet, if the naming convention is not good for you
15:10 <vmassol> again that's not hte problem
15:10 <vmassol> the explicit binding is good
15:11 <vmassol> the problems is that people in the know will start using the naming convention
15:11 <+mflorea> vmassol: isn't maven using naming conventions?
15:11 <vmassol> well first 100% of people who don't like maven is becaise it's too magical
15:11 <vmassol> and there are a lot of them
15:11 <vmassol> second we're not building a build tool
15:11 <+mflorea> but we're using it..
15:11 <vmassol> so?
15:12 <vmassol> we're even using non open source tools
15:12 <vmassol> even if I believe in OSS
15:12 <vmassol> how does that matter?
15:12 <vmassol> :)
15:12 <+mflorea> so you don't like maven's "magic"?
15:12 <vmassol> there are good points and bad ones
15:12 <vmassol> but even magic is not that magic all over
15:12 <+Denis> mflorea: at least there is a security issue with the creation of xyzClassSheet by anyone, when xyzClass and their object are in use
15:13 <+mflorea> I'm trying to understand why naming convention is good for maven and bad for us
15:13 <vmassol> mflorea: don't confuse things please
15:13 <vmassol> you're talking about apples and oranges
15:13 <vmassol> let's talk about xwiki
15:13 <+mflorea> yes, which we want to make an application platform
15:13 <@cjdelisle> register user named: XWikiRightsSheet hehe
15:13 <vmassol> if you compared xwiki with a labguage java it would be more appropriate
15:14 <vmassol> because they have more points in common than xwiki and maven
15:14 <vmassol> in any case xwiki should be extensible
15:14 <vmassol> but not magical
15:14 <vmassol> we can vote on that
15:14 <vmassol> to make sure we all agree
15:14 <vmassol> it's quite important actually
15:15 <+Denis> mflorea: this not the document xyzClass that make that document defining an xyzClass, and that should be the same for the sheet
15:15 <vmassol> since it's general direction for everything we do
15:15 <+Denis> vmassol: the direction exist already, see my last comment
15:15 <vmassol> Right now the general strategy is simple:
15:15 <vmassol> whenever we want to add a new behavior we add XObjects metadata
15:16 <vmassol> I really don't see why we would invent anything new
15:16 <vmassol> (and I don't see teh need)
15:17 <vmassol> actually we do have a bit of magic already but we want to remove it: user pages have to be in the XWiki space. That's not nice
15:17 <+mflorea> again, if you want explicit class-sheet binding then you have to add an empty sheet object just to mark a sheet
15:17 <@cjdelisle> I was thinking a similar thing: Every time we add new magic, we attach it to a built in class, if you don't want the magic, don't add an object of that class (EG: XWikiRights)
15:18 <vmassol> mflorea: and again the issue is not the explciit binding, it's with people who are going to use the magic
15:18 <vmassol> mflorea: you can see that differnetly:
15:18 <vmassol> in java they refused to do a lot of stuff asked by users
15:18 <vmassol> why?
15:18 <vmassol> because it made the language dangerous
15:18 <vmassol> people who overuse those extra features
15:19 <vmassol> s/who/would/
15:19 <vmassol> and make the language unreadable
15:19 <vmassol> it's not a good thing to popose several ways of doing something and based on some magical stuff
15:19 <vmassol> it's called overengineering if you prefer
15:20 <vmassol> it's asking for trouble, you can be sure people will abuse it
15:20 <@cjdelisle> I have one question about it: What happens if you have a document with multiple objects of the same class and what if you have multiple objects of different classes?
15:20 <JuanDaugherty> has left #xwiki
15:20 <+mflorea> cjdelisle: read the code :)
15:20 <@cjdelisle> ok, -1 until I'm done reading ;)
15:20 <+mflorea> vmassol: I'm not convinced
15:21 <vmassol> I don't know if this has any impact but in the future the model could well allow a page to have several classes
15:21 <vmassol> mflorea: it's the other way around
15:21 <vmassol> you need to convince us it's good
15:21 <vmassol> since you're changing what we're doing
15:21 <+mflorea> well I tried but I obviously failed
15:22 <@cjdelisle> I am about to offer a counterproposal which I think will make everybody happy but I want to understand how you resolve that problem.
15:22 <vmassol> personally I'm fine to release 3.2 with it because we need to release 3.2 but marked experimental and start a discussion thread on the list for 3.3 and remove it if we don't agree about it
15:23 <vmassol> but since it's starting something new (stuff based on page names) it's important we're all comfortable withi t
15:23 <+mflorea> Denis: regarding your use case, it can be prevented if you set the proper rights on the space containing the sheet. The sheet manager looks in the same space as the class. So you need edit rights on the space containing the sheet to be able to create a sheet for that class and mess the pages containing that type of objects
15:23 <+mflorea> s/space containing the sheet/space containing the class
15:23 <vmassol> because if we agree about using name as menaingful then it opens up lots of possibilities for other stuff too
15:24 <vmassol> it would need to be a general rule that we're allowed to use name convnetions to perfom actions
15:24 <+mflorea> vmassol: I'll send a vote. If you don't like it I can drop the code, it's just a few lines
15:24 <vmassol> ok sounds good to me
15:25 <vmassol> actually mflorea I think we hsould do the other way around, you're right: don't add stuff we'ren ot sure about and add it later on if it's really needed
15:25 <vmassol> rather than start with lots of options and remove some after
15:25 <vmassol> it's easier to add than remove
15:25 <vmassol> (I thought it was more than a few lines)
15:25 <vmassol> (cool to know if you could be removed quickly)
15:25 <vmassol> s/if/it/
15:26 <+Denis> mflorea: I really think your idea is well done, but nobody will understand all of it without reading the documentation, and this will cause more confusion than real magic, this precisely where we are now.
15:26 <+mflorea> DefaultSheetManager looks for naming convention if explicit binding it missing. There are just a few lines
15:27 <+Denis> I am +1 to keep explicit binding only for the release
15:29 <@cjdelisle> I think we should introduce a DisplayerClass with viewSheet, editSheet, and inlineSheet fields which can be added to the document which defines the class. It's better contained and the magic is confined to a built in class so you don't get magic unless you instanciate it.
15:30 <@cjdelisle> Also it's one less document that needs to be loaded from the db since the class has to be loaded anyway for putting together the object.
15:30 <+mflorea> @Denis: well, there is a caveat.. some classes are created ("magically" :) ) when XWiki is first run. I can't explicitly map these classes to their sheets (it would have to hard-code the name of the class used for binging in old core). In this case I used a configuration property.
15:31 <+mflorea> s/binging/binding
15:33 <+Denis> mflorea: not sure I get your last point. Isn't the existing code not using the new stuff at all, and therefore should work using simple backward compatibility ?
15:33 <+mflorea> cjdeliste: :) what if I want to apply a sheet to the document defining the class (i.e. ClassSheet). What if I'm using a different action? In the new model you'll be able to have custom actions... I really spent time thinking about the sheet system..
15:35 <@cjdelisle> you mean if the class contains an object of it's own type?
15:35 <+mflorea> Denis: sooner or later we'd have to move to the new system, and then we're gonna it the problem: there are classes created automatically in old core that have to explicitly binded to their sheets
15:35 <@cjdelisle> *class document
15:36 <+Denis> mflorea: and what is the problem with that ?
15:36 <+mflorea> cjdelisle: yes, and also if you want to apply a custom sheet for a document. The system I implemented allows you to apply a custom sheet for a single document
15:37 <@cjdelisle> also shouldn't it only take effect if the document has no content?
15:38 <+mflorea> Denis: ClassSheetBinding is an implementation detail for the DefaultSheetManager. i.e. the default sheet manager uses this class to mark that a class is bound to a sheet. The code in oldcore shouldn't be aware of this and shouldn't hard-code the name of this class
15:39 <@cjdelisle> if you wanted to support as yet unknown actions, you could use an ActionDisplayerClass where it has 2 fields: action and classSheet
15:40 <+mflorea> cjdelisle: the purpose of the sheet is to display the document. Take the blog post example. The blog should _really_ use the document title and document content for the blog post title and content. The sheet displaying the blog post decides what to do with the blog post title and content. In other words the sheet is a function of the document
15:41 <+mflorea> cjdelisle: I have ClassSheetBinding which specifies the sheet and SheetClass which specifies the action, it's already implemented
15:41 <@cjdelisle> ok
15:41 <@cjdelisle> If you don't like the idea of implementing the sheet as an object that's fine but I don't like the idea of magical document names.
15:42 <+mflorea> I understood very well that :)
15:42 <@cjdelisle> heh
15:42 <+Denis> mflorea: you means that the oldcore is unable to create classSheetBinding object ?
15:43 <JuanDaugherty> has joined #xwiki
15:43 <+mflorea> it is able, but by using ClassSheetBinding class it means it will work only with the DefaultSheetManager, which is bad. SheetManager is a component, and you should be able to use a different impl that uses some other classes to mark that a class is bound to a sheet
15:43 <+mflorea> @Denis
15:45 <+mflorea> i.e. ideally only DefaultSheetManager (from java code at least) should know that a sheet is bound to a class using ClassSheetBinding object
15:45 <jvdrean> has joined #xwiki
15:46 <+Denis> mflorea: I understand that, but this is link to the oldcore, a new core would not suffer that
15:46 <+mflorea> sure
15:46 <+Denis> so while the oldcore exist, we have to live with that limitation IMO
15:47 <+mflorea> hmm, I think there is also the issue that ClassSheetBinding is not present when XWiki starts, i.e. before you import the xar, so actually I doubt you can create an object of this type..
15:48 <+Denis> I just wonder, the SheetManager interface should provide ways to define sheet association and create the binding object
15:48 <+Denis> no ?
15:48 <+mflorea> until know the include macro was used, so you could simply write literally "{{include document=\"SomeSheet\" /}}" but know you have to create an object
15:50 <+mflorea> Denis: I added them at one point but I removed them because I didn't implement them for 3.2 release
15:50 <+mflorea> i.e. I added them to the interface
15:50 <+Denis> when them exist, wouldn't the old core be able to use it ?
15:51 <+mflorea> I guess so, but then the DefaultSheetManager would have to create them in the initialization phase (implements Initializable). Right now they are in the sheet
15:52 <+mflorea> s/sheet/xar
15:54 <+Denis> yes and for now they will continue to work using backcompat
15:55 <pturcotte> has quit
15:55 <+mflorea> yes (I'll have to re-add some code I deleted from old core, now that the magic has gone )
15:56 <pturcotte> has joined #xwiki
16:03 <sdumitriu> has joined #xwiki
16:45 <JuanDaugherty> why does workspaces 1.1 rc2 have so much stuff in it?
16:46 <vmassol> JuanDaugherty: yep was going to say that
16:46 <vmassol> now the only person who could answer your question is jerome velociter since I think he's the only one to have worked on it ;)
16:48 <JuanDaugherty> ah.
16:50 <+Denis> mflorea: for your last thread on ML, are you asking for 3.2 or in general ?
16:50 <+mflorea> 3.2
16:51 <+mflorea> note that it's easy to drop steps of the algorithm
16:51 <+mflorea> so don't take into account the time needed to make the adjustments when voting
16:53 <+Denis> yes, its is just that in general I have doubt on put the relation between sheet and class, on the class
16:54 <+Denis> the class is a class, the doc is data, and the sheet is the code, so I would have seen the binding object in the sheet document
16:54 <+mflorea> well :) the reason it exactly why you don't like the magic: someone can create a page XyzClassSheet and thus break your pages. If you define the binding the sheet then anyone can define the sheet
16:55 <+Denis> this is security matters, but it would not be incouscious
16:55 <+mflorea> my initial idea was that you should have edit rights on the class to be able to bind it to a sheet
16:55 <JuanDaugherty> it looks like jvelociter left the xwiki project c. 3.0
16:56 <+tmortagne> JuanDaugherty: he left XWiki SAS company, not XWiki project
16:56 <JuanDaugherty> ah, I guess that distinction isn't clear enough in my mind yet
16:56 <+tmortagne> and this is more recent that 3.0
16:56 <JuanDaugherty> this?
16:56 <+tmortagne> him living XWiki SAS
16:56 <JuanDaugherty> ah
16:58 <+tmortagne> JuanDaugherty: you could think of it as XWiki SAS having lots of XWiki project contributors in its staff but that's pretty much all, some XWiki project committers are not XWiki SAS employees
16:59 <JuanDaugherty> got it
16:59 <+tmortagne> (and also providing server for xwiki.org)
17:00 <vmassol> JuanDaugherty: you could also read this past email: http://markmail.org/thread/4omxwpung2todjqf
17:00 <vmassol> although the links are probably not correct anymore....
17:01 <vmassol> this one is still valid: http://massol.myxwiki.org/xwiki/bin/view/Blog/XWikiSASAndOpenSource
17:01 <+mflorea> Denis: also, putting the binding in the sheet document could make it more expensive (?) to find the sheet because you have to query the db for all sheets, where "class" prop points to your class.
17:01 <JuanDaugherty> lol 12.5 comitters
17:01 <+tmortagne> :)
17:02 <vmassol> and more here too: http://www.xwiki.com/xwiki/bin/view/Community/OpenSource
17:02 <vmassol> hehe
17:02 <vmassol> don't remember who was the half, probably guillaume ;)
17:03 <+Denis> mflorea: these (rights/perfs) are implementation matter, and the reason for my doubts
17:03 <JuanDaugherty> Dubost is no longer involved?
17:08 <vmassol> he's still a committer
17:08 <vmassol> not very active
17:08 <vmassol> a few commiters every 4-5 months
17:08 <vmassol> s/commiters/commits/
17:08 <vmassol> he's mostly busy running the xwiki sas company
17:08 <JuanDaugherty> i c. He appears to be part of the same venture as jvelociter
17:09 <JuanDaugherty> ie. "winesquare"
17:09 <vmassol> if by venture you mean that they both are working for XWiki SAS then yes
17:09 <vmassol> ah no
17:09 <vmassol> winesquare is the new project from jerome
17:09 <vmassol> ludovic isn't involved
17:09 <vmassol> that's why he left xwiki sas, to start his own startup around this project
17:10 <JuanDaugherty> it says he is on their site
17:10 <vmassol> (winesquare is basedon the xwiki platform btw ;))
17:10 <vmassol> really?
17:10 <vmassol> never checked his web site actually
17:10 <vmassol> looking
17:10 <vmassol> link?
17:10 <JuanDaugherty> no, my bad on their site they have a FB thing which
17:10 <vmassol> right
17:10 <JuanDaugherty> has him having given a like
17:11 <JuanDaugherty> .
17:11 <vmassol> yep
17:11 <vmassol> and there's me now too
17:11 <vmassol> :)
17:11 <vmassol> (just gave a "like")
17:13 <evalica> has quit
17:16 <JuanDaugherty> i see you have been working on workspaces design ( http://dev.xwiki.org/xwiki/bin/view/Design/Workspaces ). Is there anything I should be cognizant of in current stable or upcoming 3.2 on this?
17:26 <vmassol> JuanDaugherty: you shouldn't use workspaces
17:26 <vmassol> it's been retired as you know
17:26 <vmassol> and we've integrated several of its features in XE
17:26 <vmassol> (and no I haven't worked on the design of workspaces)
17:27 <JuanDaugherty> I meant the concept with the URL I just gave, not jvelociter's project
17:27 <JuanDaugherty> besides it's not being supported, why shouldn't I use it?
17:27 <JuanDaugherty> *its
17:28 <vmassol> you can of course but don't expect any support for it. I have for ex no clue that it can even start up or work
17:29 <Enygma`> has quit
17:29 <jvdrean> has quit
17:30 <JuanDaugherty> yeah, it doesn't look well formed which is unfortunate since as your design salient indicates, there is pressing functionality there that one might want to use
17:30 <JuanDaugherty> s/formed/packaged, presented, whatever/
17:30 <jvdrean> has joined #xwiki
17:31 <vmassol> JuanDaugherty: if youhave a need you should talk about it
17:31 <vmassol> maybe it's already covered by an XE extension
17:31 <JuanDaugherty> no I don't think so
17:32 <vmassol> hmm unless you're talking about the new workspaces
17:33 <vmassol> this one http://dev.xwiki.org/xwiki/bin/view/Design/Workspaces has nothing to do with XWiki Workspaces done by Jerome Velociter
17:33 <vmassol> it's a new project and will be released as an XE extension very soon
17:34 <JuanDaugherty> that does appear to be the same URL I mentioned parenthetically above
17:34 <JuanDaugherty> very soon means after 3.2?
17:35 <vmassol> yes it is but I thought you were continuing on the discussion about the retired xwiki workspaces (XWS)
17:35 <vmassol> yes probably soon after 3.2
17:35 <JuanDaugherty> why would I do that?
17:35 <vmassol> sorry got to go work a bit
17:35 <JuanDaugherty> k, great, thx
17:35 <vmassol> ttyl
17:50 <abusenius> has joined #xwiki
17:56 <vmassol> has quit
17:59 <vmassol> has joined #xwiki
17:59 <sburjan> has quit
18:02 <vmassol> has quit
18:21 <vmassol> has joined #xwiki
18:50 <mflorea> has quit
19:51 <pturcotte> has quit
19:53 <pturcotte> has joined #xwiki
20:12 <Enygma`> has joined #xwiki
20:20 <+sburjan`> cjdelisle: around ?
20:23 <@cjdelisle> I am but not for much longer
20:23 <@cjdelisle> what's up?
20:23 <+sburjan`> just one question
20:23 <+sburjan`> regarding the EM permanent directory vote
20:24 <+sburjan`> option #2 will mean that if you want to run the xwiki as another user, you will have to move t he ~./xwiki dir to the new user's homedir, right ?
20:24 <@cjdelisle> correct.
20:25 <+sburjan`> ok. just wanted to know it for sure
20:25 <@cjdelisle> on a production machine it should really always run as "tomcat" though
20:25 <+sburjan`> yepp. or www (httpd)
20:25 <@cjdelisle> yup
20:50 <tmortagne> has quit
21:21 <vmassol> has quit
21:21 <mflorea> has joined #xwiki
23:12 <pturcotte> has quit
23:28 <Enygma`> has quit
23:39 <abusenius> has quit
23:54 <mflorea> has quit
