Search: concept

view=externalLinks 14:38 <vmassol> even though this is in the commons wiki you can see all links for all wikis 14:40 <+tmortagne> that page could be aware of multiwiki concept, where is the API which require multiwiki information exactly ?

14:40 <+tmortagne> does not remember anything like this 14:40 <+mflorea> I don't remember, nevermind, I'll keep searching 14:41 <vmassol> tmortagne: that has 2 issues. 1) we still have the script service in rendering which can be accessed and 2) it's costly to parse all references to filter them 14:41 <+tmortagne> mflorea: search is supposed to be case sensitive from what I know unless you did not properly configured MySQL database 14:41 <vmassol> one solution I can think of would be to have a system to inject the structure 14:41 <vmassol> ideally we'd need the resources module 14:42 <vmassol> (i think) 14:42 <+tmortagne> vmassol: I don't say the solution is to filter in that page I'm asking where the multiwiki concept is really required 14:42 <vmassol> tmortagne: IMO each wiki should only list the links for itself and the main wiki should list all links 14:43 <+tmortagne> you mean duplicate them ?

14:56 <+tmortagne> the catch of the links to check 14:56 <+tmortagne> instead of rendering 14:56 <+tmortagne> linckchecker store itself can stay in commons if it provide a concept of namespace 14:56 <vmassol> well if we do this we might as well move the whole thing to platform 14:56 <vmassol> if we add the concept of namespace then we're good 14:57 <+tmortagne> for the storage but rendering alone cannot extract the namespace 14:57 <vmassol> we just need to add an interface to extract the namespace from the string 14:57 <vmassol> the impl would be in platform indeed 14:57 <vmassol> with a default impl in rendering that does nothing 14:57 <vmassol> (empty namespace) 14:58 <vmassol> I was just thinking that this namespace need is more generic than just hte link checker 14:58 <vmassol> and this could fit in the resource module we talked about 14:58 <vmassol> provided we agree to add the concept of namespace in the resource module 14:58 <vmassol> anyway it's a bit too early for such a module but the interest is growing 14:59 <+tmortagne> it's more generic that lin kchcker for sure since it already exist in EM and multi CM as I told you 14:59 <vmassol> yep 14:59 <vmassol> do you have already interfaces for extracting namespaces somewhere?

abusenius - (11:57): well, depends on what you are trying to do cjdelisle - (11:58): I just want to be able to sign different stuff until I can get different code to have the same signature. abusenius - (11:58): well, then you need another test I guess abusenius - (11:58): and good luck with forging :) abusenius - (12:06): btw, back to signing with browser, IMO the best thing is (also for signing on server side) abusenius - (12:06): is to present the text that should be signed to the user first cjdelisle - (12:06): yup, you have no choice in firefox. abusenius - (12:06): and then have some button "Do you want to sign this" cjdelisle - (12:06): It's kind of silly to let a user sign something without knowing it. cjdelisle - (12:07): takes away the concept of "signing". abusenius - (12:07): but the thing that shouöld be signed will be constructed on the server abusenius - (12:07): yes abusenius - (12:07): I'm currently making the "mangling" to behave exactly as pretty-printing cjdelisle - (12:07): Why construct it at the server?

abusenius - (11:57): well, depends on what you are trying to do cjdelisle - (11:58): I just want to be able to sign different stuff until I can get different code to have the same signature. abusenius - (11:58): well, then you need another test I guess abusenius - (11:58): and good luck with forging :) abusenius - (12:06): btw, back to signing with browser, IMO the best thing is (also for signing on server side) abusenius - (12:06): is to present the text that should be signed to the user first cjdelisle - (12:06): yup, you have no choice in firefox. abusenius - (12:06): and then have some button "Do you want to sign this" cjdelisle - (12:06): It's kind of silly to let a user sign something without knowing it. cjdelisle - (12:07): takes away the concept of "signing". abusenius - (12:07): but the thing that shouöld be signed will be constructed on the server abusenius - (12:07): yes abusenius - (12:07): I'm currently making the "mangling" to behave exactly as pretty-printing cjdelisle - (12:07): Why construct it at the server?

The initial prototype is promising but wil need work to allow concurrent access and faster handling of big volumes of data. Currently the concept is ongoing translation. Reimport of the main language (english) file can be done regularly.

Once it is loaded on launchpad.net there is a quite extensively developed translation application. The concept seems to work by application version. We need to verity if this is the way we want it to work.

The initial prototype is promising but wil need work to allow concurrent access and faster handling of big volumes of data. Currently the concept is ongoing translation. Reimport of the main language (english) file can be done regularly.

Once it is loaded on launchpad.net there is a quite extensively developed translation application. The concept seems to work by application version. We need to verity if this is the way we want it to work.

I'd like to see the diff between 5 and 6 and 4, I'd be towards including them in the round 2 too, but it depends vmassol - (14:16): the first 2 in the new round should be discarded imo vmassol - (14:17): they're too close to the xwiki sas logo lucaa - (14:18): 12A is, 12E not that much. vmassol - (14:18): lucaa: it is, the concept is the same vmassol - (14:18): ask ciprian I'm sure he'll tell you he copied the concept from the current xwiki sas ologo tmortagne - (14:18): IMO 15 is way too close to atlassian, i would at least vote -0 for it vmassol - (14:19): tmortagne: I don't think so on this one, the concept is different vmassol - (14:19): very different vmassol - (14:19): in our case it represents an X for XWiki vmassol - (14:19): the one we discarded was ok for me too tmortagne - (14:19): first thing a user see is that it represent a human, then it represent a X vmassol - (14:19): since even though it represented a person, it was also the X from XWiki vmassol - (14:20): I think it's defendable vmassol - (14:20): (in court) vmassol - (14:20): but I'm no expert ;) tmortagne - (14:21): sure but better having a logo for which there is no similrality with our principal competitor event if "it's defendable"... vmassol - (14:24): yes but we need to keep a few proposals ;) lucaa - (14:26): yeah, the pb is that atlassian has an X-shaped logo :) vmassol - (14:26): IMO these logos were done withut the atlassian logo in mind vmassol - (14:26): yes lucaa, wanted to say the same thing vmassol - (14:26): they stole our X!

I'd like to see the diff between 5 and 6 and 4, I'd be towards including them in the round 2 too, but it depends vmassol - (14:16): the first 2 in the new round should be discarded imo vmassol - (14:17): they're too close to the xwiki sas logo lucaa - (14:18): 12A is, 12E not that much. vmassol - (14:18): lucaa: it is, the concept is the same vmassol - (14:18): ask ciprian I'm sure he'll tell you he copied the concept from the current xwiki sas ologo tmortagne - (14:18): IMO 15 is way too close to atlassian, i would at least vote -0 for it vmassol - (14:19): tmortagne: I don't think so on this one, the concept is different vmassol - (14:19): very different vmassol - (14:19): in our case it represents an X for XWiki vmassol - (14:19): the one we discarded was ok for me too tmortagne - (14:19): first thing a user see is that it represent a human, then it represent a X vmassol - (14:19): since even though it represented a person, it was also the X from XWiki vmassol - (14:20): I think it's defendable vmassol - (14:20): (in court) vmassol - (14:20): but I'm no expert ;) tmortagne - (14:21): sure but better having a logo for which there is no similrality with our principal competitor event if "it's defendable"... vmassol - (14:24): yes but we need to keep a few proposals ;) lucaa - (14:26): yeah, the pb is that atlassian has an X-shaped logo :) vmassol - (14:26): IMO these logos were done withut the atlassian logo in mind vmassol - (14:26): yes lucaa, wanted to say the same thing vmassol - (14:26): they stole our X!

arkub left at 19:38 (Quit: Leaving sdumitriu - (19:39): We can't ask all designers factor - (19:39): ok getting the hang of it using the velocity code to do forms and it is working marta1 joined #xwiki at 19:39 sdumitriu - (19:39): And we'll forever find new people that didn't find out about this the first (or second, or third) time gvallarelli - (19:39): sdumitriu, no only designers who commits to open source projects vmassol1 - (19:40): gvallarelli: it doesn't matter, we're not looking for the best logo ever sdumitriu - (19:40): Each project has its designers vmassol1 - (19:40): we just want a good enough logo vmassol1 - (19:40): preferably done by the community sdumitriu - (19:40): We could ask mozilla designers, eclipse designers, kde designers, gnome designers... sdumitriu - (19:40): But Firefox and Eclipse also did the same thing as we did sdumitriu - (19:41): Plan a schedule and stick to it gvallarelli - (19:41): In medio stat virtus sdumitriu - (19:41): Announce the challenge, see what comes in gvallarelli - (19:41): or aurea mediocritas sdumitriu - (19:42): And, it's hard from someone not from the community to come with a good logo, one that represents XWiki well gvallarelli - (19:42): I don't think so gvallarelli - (19:42): designers could create logo based on concept or idea gvallarelli - (19:43): for example I have an idea about a logo gvallarelli - (19:43): but I'm not able to realize it gvallarelli - (19:43): :( sdumitriu - (19:43): Collaborate sdumitriu - (19:43): The first step was about concepts, not designs sdumitriu - (19:44): You could have proposed a pen-on-paper+camera logo gvallarelli - (19:44): my idea is about an hand that take a pen and draw an X gvallarelli - (19:44): on a paper background gvallarelli - (19:44): a stylized hand sdumitriu - (19:45): vmassol1: Agree with the -1 votes?

vmassol1 - (20:01): you vote for stuff not against vmassol1 - (20:01): what we need to agree *before* the vote is about the logos with ressemblances sdumitriu - (20:01): vmassol1: Well, this was just so that you can make your opinion about 12 count sdumitriu - (20:01): mflorea: http://dev.xwiki.org/xwiki/bin/view/Community/LogoChallengeRound2 mflorea - (20:02): sdumitriu: I haven't followed the discussion mflorea - (20:02): ok, let me read sdumitriu - (20:02): vmassol1: We did agree before, you just didn't pay attention sdumitriu - (20:03): mflorea: The debate is about proposals 12 and 15; Vincent thinks that 12 resembles the current logo too much and should be discarded, tmortagne thinks that 15 resembles Atlassian too much and should be discarded sdumitriu - (20:04): So, options are: sdumitriu - (20:04): 1/ elliminate 12 and 15 now, although they are the most popular, and continue the second round with the following 3-4 most voted proposals sdumitriu - (20:04): 2/ elliminate 12 and 15 and start the vote again sdumitriu - (20:04): 3/ keep them and live with the result vmassol1 - (20:05): not all 12 sdumitriu, just the one with the same concepts sdumitriu - (20:05): 4/ better ideas welcome vmassol1 - (20:05): s/concepts/concept/ vmassol1 - (20:05): sorry guys, dinner time here, bb after gvallarelli - (20:06): http://img547.imageshack.us/img547/6131/logo.png gvallarelli - (20:06): It could be stylized by an artist gvallarelli - (20:06): but this is my idea gvallarelli - (20:07): it recalls wikipedia logo sdumitriu - (20:07): Going to cook, too mflorea - (20:0

CalebJamesDeLisl - (00:18): No it's all handles by firefox internals, no need to tinker with javascript. abusenius - (00:18): ok, cool abusenius - (00:19): I have some proof of concept implementation of signed scripts abusenius - (00:19): https://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-rendering-macro-signed abusenius - (00:20): it can currently just do create/verify, is not persistent but shows the point abusenius - (00:20): there is also a small app that shows some of the methods CalebJamesDeLisl - (00:20): What I have is based on bblfish's work, i can create client certs and make a client able to sign text from their browser. abusenius - (00:21): we need to merge our implementations somehow CalebJamesDeLisl - (00:21): I have been trying to figure out how to validate pkcs7 signatures, looks like you have that done which is great. abusenius - (00:21): at least they should be compatible :) abusenius - (00:22): yes, so I basically need to add some api to give you the data to sign, then you can post it back abusenius - (00:22): and you can allready import a new trusted cert abusenius - (00:22): (if the format will match) CalebJamesDeLisl - (00:22): We all sort of have to work around the firefox crypto.signText standard if we want to support client certs.

CalebJamesDeLisl - (00:18): No it's all handles by firefox internals, no need to tinker with javascript. abusenius - (00:18): ok, cool abusenius - (00:19): I have some proof of concept implementation of signed scripts abusenius - (00:19): https://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-rendering-macro-signed abusenius - (00:20): it can currently just do create/verify, is not persistent but shows the point abusenius - (00:20): there is also a small app that shows some of the methods CalebJamesDeLisl - (00:20): What I have is based on bblfish's work, i can create client certs and make a client able to sign text from their browser. abusenius - (00:21): we need to merge our implementations somehow CalebJamesDeLisl - (00:21): I have been trying to figure out how to validate pkcs7 signatures, looks like you have that done which is great. abusenius - (00:21): at least they should be compatible :) abusenius - (00:22): yes, so I basically need to add some api to give you the data to sign, then you can post it back abusenius - (00:22): and you can allready import a new trusted cert abusenius - (00:22): (if the format will match) CalebJamesDeLisl - (00:22): We all sort of have to work around the firefox crypto.signText standard if we want to support client certs.

10:46 <+tmortagne> you probably need to separate the WYSIWYG server module in two 10:47 <+tmortagne> one without any context concept and one with it 10:47 <+mflorea> I'm trying to keep WEB-INF/lib small, it already has 30 something deps, coming from xwiki-commons-component-default, xwiki-rendering-syntax-xwiki21 and xwiki-commons-xml 10:47 <+tmortagne> like we have a rendering-xwiki module on platform side to add stuff we do'nt want in base rendeing 10:47 <+mflorea> yes, that is the clean solution, but for now I'll just overwrite that class in my war, in WEB-INF/classes 10:47 <+tmortagne> that's a good thing to do anyway to move the WYSIWYG to rendering 10:48 <+tmortagne> or to it's own repo 10:49 <+mflorea> there are a couple of refactorings that could be done on the WYSIWYG module, but I just want to make a quick demo for now :) 10:49 <+tmortagne> ok 11:01 <+Enygma`> xwiki-platform is failing because of a clirr error: http://ci.xwiki.org/job/xwiki-platform/2616/consoleFull 11:02 <+Enygma`> this commit https://github.com/xwiki/xwiki-platform/commit/9d00d822615840f1b27c753091b8c75aca9d58ed has been pushed between 4.2RC1 and 4.2Final but only on the master branch, so it is not present in 4.2Final 11:03 <+mflorea> [ERROR] com.xpn.xwiki.plugin.mailsender.MailSender: Method 'public int sendMessageFromTemplate(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.util.Map)' has been removed 11:03 <+mflorea> I guess Sergiu reverted the commit only from master 11:03 <+Enygma`> yes, that method was added before 4.2RC1 and then removed before 4.2Final 11:03 <+Enygma`> right... 11:04 <+Enygma`> so we either go ahead and add an exception for it, or, if jvelo is not yet done with the release, we could re-release xwiki-platform with the commit included 11:04 <+mflorea> or add the method to master again, if it's useful 11:05 <+Enygma`> right, as in revert this recent commit 11:06 <jvelo> has quit 12:37 <mflorea> has quit 12:48 <npm_> has quit 12:49 <npm_> has joined #xwiki 13:40 <mflorea> has joined #xwiki 14:16 <eshan> has quit 15:41 <jvelo> has joined #xwiki 16:15 <jvelo> has quit 16:37 <vmassol> has quit 16:39 <vmassol> has joined #xwiki 17:00 <jvelo> has joined #xwiki 17:03 <jvelo> Hi guys.

10:46 <+tmortagne> you probably need to separate the WYSIWYG server module in two 10:47 <+tmortagne> one without any context concept and one with it 10:47 <+mflorea> I'm trying to keep WEB-INF/lib small, it already has 30 something deps, coming from xwiki-commons-component-default, xwiki-rendering-syntax-xwiki21 and xwiki-commons-xml 10:47 <+tmortagne> like we have a rendering-xwiki module on platform side to add stuff we do'nt want in base rendeing 10:47 <+mflorea> yes, that is the clean solution, but for now I'll just overwrite that class in my war, in WEB-INF/classes 10:47 <+tmortagne> that's a good thing to do anyway to move the WYSIWYG to rendering 10:48 <+tmortagne> or to it's own repo 10:49 <+mflorea> there are a couple of refactorings that could be done on the WYSIWYG module, but I just want to make a quick demo for now :) 10:49 <+tmortagne> ok 11:01 <+Enygma`> xwiki-platform is failing because of a clirr error: http://ci.xwiki.org/job/xwiki-platform/2616/consoleFull 11:02 <+Enygma`> this commit https://github.com/xwiki/xwiki-platform/commit/9d00d822615840f1b27c753091b8c75aca9d58ed has been pushed between 4.2RC1 and 4.2Final but only on the master branch, so it is not present in 4.2Final 11:03 <+mflorea> [ERROR] com.xpn.xwiki.plugin.mailsender.MailSender: Method 'public int sendMessageFromTemplate(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.util.Map)' has been removed 11:03 <+mflorea> I guess Sergiu reverted the commit only from master 11:03 <+Enygma`> yes, that method was added before 4.2RC1 and then removed before 4.2Final 11:03 <+Enygma`> right... 11:04 <+Enygma`> so we either go ahead and add an exception for it, or, if jvelo is not yet done with the release, we could re-release xwiki-platform with the commit included 11:04 <+mflorea> or add the method to master again, if it's useful 11:05 <+Enygma`> right, as in revert this recent commit 11:06 <jvelo> has quit 12:37 <mflorea> has quit 12:48 <npm_> has quit 12:49 <npm_> has joined #xwiki 13:40 <mflorea> has joined #xwiki 14:16 <eshan> has quit 15:41 <jvelo> has joined #xwiki 16:15 <jvelo> has quit 16:37 <vmassol> has quit 16:39 <vmassol> has joined #xwiki 17:00 <jvelo> has joined #xwiki 17:03 <jvelo> Hi guys.

xwiki-bridge - (14:27): [tmortagne] component configuration, xwiki.properties xwiki-bridge - (14:27): [tmortagne] like we do for cache xwiki-bridge - (14:27): [lucaa] ok, properties xwiki-bridge - (14:27): [tmortagne] you choose in xwiki.prtoperties if you want to use jbosscache or oscache implemenattion xwiki-bridge - (14:27): [lucaa] ok xwiki-bridge - (14:28): [tmortagne] or the velocity macro filter xwiki-bridge - (14:28): [Vincent Massol] wait xwiki-bridge - (14:28): [Vincent Massol] I don't think this is correct xwiki-bridge - (14:28): [Vincent Massol] we already support the ability to swap implementations xwiki-bridge - (14:28): [Vincent Massol] by registering a component with the same hint xwiki-bridge - (14:28): [Vincent Massol] we shouldn't care about "scribo" in XE xwiki-bridge - (14:29): [Vincent Massol] nor should we care about exposing a way to override the component impl xwiki-bridge - (14:29): [Vincent Massol] (since it's a default feature of the CM) xwiki-bridge - (14:29): [lucaa] I assumed there are solutions, it's not that important, it's just a matter of approach, the way to operate with components xwiki-bridge - (14:29): [lucaa] I know you can override xwiki-bridge - (14:29): [Vincent Massol] using different hints for different impl is wrong xwiki-bridge - (14:29): [Vincent Massol] a hint represents a concept xwiki-bridge - (14:30): [Vincent Massol] not an impl xwiki-bridge - (14:30): [Vincent Massol] "scribo" is not a concept xwiki-bridge - (14:30): [tmortagne] Vincent Massol: what is a concept ?

xwiki-bridge - (14:27): [tmortagne] component configuration, xwiki.properties xwiki-bridge - (14:27): [tmortagne] like we do for cache xwiki-bridge - (14:27): [lucaa] ok, properties xwiki-bridge - (14:27): [tmortagne] you choose in xwiki.prtoperties if you want to use jbosscache or oscache implemenattion xwiki-bridge - (14:27): [lucaa] ok xwiki-bridge - (14:28): [tmortagne] or the velocity macro filter xwiki-bridge - (14:28): [Vincent Massol] wait xwiki-bridge - (14:28): [Vincent Massol] I don't think this is correct xwiki-bridge - (14:28): [Vincent Massol] we already support the ability to swap implementations xwiki-bridge - (14:28): [Vincent Massol] by registering a component with the same hint xwiki-bridge - (14:28): [Vincent Massol] we shouldn't care about "scribo" in XE xwiki-bridge - (14:29): [Vincent Massol] nor should we care about exposing a way to override the component impl xwiki-bridge - (14:29): [Vincent Massol] (since it's a default feature of the CM) xwiki-bridge - (14:29): [lucaa] I assumed there are solutions, it's not that important, it's just a matter of approach, the way to operate with components xwiki-bridge - (14:29): [lucaa] I know you can override xwiki-bridge - (14:29): [Vincent Massol] using different hints for different impl is wrong xwiki-bridge - (14:29): [Vincent Massol] a hint represents a concept xwiki-bridge - (14:30): [Vincent Massol] not an impl xwiki-bridge - (14:30): [Vincent Massol] "scribo" is not a concept xwiki-bridge - (14:30): [tmortagne] Vincent Massol: what is a concept ?

if it's "xwiki-core specific", no it's ok since we already have multiwiki concept in wiki macro visibility vmassol - (16:35): ok found the answer vmassol - (16:36): XWIKI-5622: New event types: add/update/delete comment/annotation/attachment vmassol - (16:36): lots of issues for the same topic…. got lost lucaa - (16:36): tmortagne: yeah, i mean xwiki-core, the fact that the "wiki with the name xx" is an xwiki concept.

if it's "xwiki-core specific", no it's ok since we already have multiwiki concept in wiki macro visibility vmassol - (16:35): ok found the answer vmassol - (16:36): XWIKI-5622: New event types: add/update/delete comment/annotation/attachment vmassol - (16:36): lots of issues for the same topic…. got lost lucaa - (16:36): tmortagne: yeah, i mean xwiki-core, the fact that the "wiki with the name xx" is an xwiki concept.

sburjan - (15:51): sdumitriu, : I've updated the page with screenshots sdumitriu - (15:52): You can't properly escape 2.0 wiki syntax lucaa - (15:52): because what happens right now is that the existing dashboard proof of concept doesn't work anymore lucaa - (15:52): and all it did was to include some macro calls in other macros sdumitriu - (15:52): And maybe it should allow normal wiki syntax, like bold and italic flaviusolaru1 - (15:52): i have a groovy script flaviusolaru1 - (15:52): def globalvar = "helau"; flaviusolaru1 - (15:52): def func() { flaviusolaru1 - (15:52): return globalvar; flaviusolaru1 - (15:52): } flaviusolaru1 - (15:52): any ideeas why is not working?

sburjan - (15:51): sdumitriu, : I've updated the page with screenshots sdumitriu - (15:52): You can't properly escape 2.0 wiki syntax lucaa - (15:52): because what happens right now is that the existing dashboard proof of concept doesn't work anymore lucaa - (15:52): and all it did was to include some macro calls in other macros sdumitriu - (15:52): And maybe it should allow normal wiki syntax, like bold and italic flaviusolaru1 - (15:52): i have a groovy script flaviusolaru1 - (15:52): def globalvar = "helau"; flaviusolaru1 - (15:52): def func() { flaviusolaru1 - (15:52): return globalvar; flaviusolaru1 - (15:52): } flaviusolaru1 - (15:52): any ideeas why is not working?

I was just pleasantly surprised by the concept of special cases :) tmortagne - (16:02): lucaa: yes i don't like it either silviar2 left at 16:02 (Quit: Leaving. tmortagne - (16:02): but i think abusenius made it cleaner than if equals("include") tmortagne - (16:02): with a interface or something i'm not sure i would have to look at it lucaa - (16:03): I'm not very happy with this idea because, while it should prevent attacks, it actually seems to make quite legitimate things impossible tmortagne - (16:03): in any case we should do the exact same thing for wiki macro lucaa - (16:03): not idea actually, implementation or something lucaa - (16:03): yes, maybe doing the same thing for wiki macros will fix it lucaa - (16:04): (as in we won't discover other special cases) tmortagne - (16:04): lucaa: there was lot's of discussion an vote for this (and i always voted no more than 0 for this kind of issues) lucaa - (16:04): yes, I missed the discussion, obviously lucaa - (16:04): anyway, better late than never lucaa - (16:04): who wants to handle it lucaa - (16:04): ?

1 to apply it as is vmassol - (11:34): (after a quick review) vmassol - (11:34): it adds the notion of scripts in several places vmassol - (11:34): which shouldn't be aware of that CalebJamesDeLisl - (11:35): -1 to the concept of blocking script in script? vmassol - (11:35): (MAcroMaarkerBlock for ex) tmortagne - (11:35): i don't even understand why he needs that vmassol - (11:36): CalebJamesDeLisl: no, ?

1 to apply it as is vmassol - (11:34): (after a quick review) vmassol - (11:34): it adds the notion of scripts in several places vmassol - (11:34): which shouldn't be aware of that CalebJamesDeLisl - (11:35): -1 to the concept of blocking script in script? vmassol - (11:35): (MAcroMaarkerBlock for ex) tmortagne - (11:35): i don't even understand why he needs that vmassol - (11:36): CalebJamesDeLisl: no, ?

CalebJamesDeLisl - (12:24): he didn't like that idea ^^ vmassol - (12:24): :) CalebJamesDeLisl - (12:25): Ok, an alternative for the moment would be to make escapetool.xml escape { CalebJamesDeLisl - (12:26): Since it looks like we're going to have to add the concept of "can nest", "cannot nest" and "reset nesting". abusenius - (12:28): btw the problem with {{include }} will remain in both cases vmassol - (12:29): lunch time arkub left at 12:34 (Ping timeout: 258 seconds CalebJamesDeLisl - (12:56): "// included documents intercept the chain of nested script macros with XWiki syntax" K.

abusenius - (17:26): no abusenius - (17:26): hm, ok NP exception abusenius - (17:26): well its 5400 CalebJamesDeLisl - (17:27): All my disks are 5400 but their big. mariusbutuc left #xwiki at 17:27 CalebJamesDeLisl - (17:28): You could instantiate ScriptMacroUtils with the dependency. tmortagne - (17:28): or make it an internal component tmortagne - (17:28): (O:-)) CalebJamesDeLisl - (17:29): There's a concept of internal components without public api?