18 Jul
2009
18 Jul
'09
3:39 a.m.
Hi
Currently our company is using Magnolia (magnolia.info) as the CMS for our website.
Because our website is not very dynamic, big or complex using Magnolia is often a little
bit of an overkill and keeping it up to date is not easy. So I was wondering if I could
use XWiki to create a simple application that would enable the creation and maintenance of
a website.
Today the Blog is a list of Blog Document building up the blog page. Breaking up the page
into a header, left and right side bar (or using the panels) and columns for the content
it should be possible to define a web page. The parts of a page a defined by classes and
the content is provided by objects. The application just provides the code that displays
the web site and additional elements to create, edit and remove parts of the document
(paragraphs) when the user is in edit mode.
The application would provide a simple web site but also the framework to create a custom
web site by extending the application.
What do you think?
Andreas Schaefer
CEO of Madplanet.com Inc.
EMail: andreas.schaefer(a)madplanet.com
schaefera(a)me.com
Twitter: andy_mpc
AIM: schaefera(a)me.com
18 Jul
18 Jul
11:35 a.m.
Hi,
Indeed, XWiki is very close to a CMS and actually often used for this
(we use it for xwiki.com and xwiki.org).
When you look at it, most CMS work like this:
1/ Admin interface allowing to create a page, setup where it will show
up (on the home page, in a category menu, in a tag menu, in a Tree menu)
but not yet publish it
2/ Review with simple (most often) or more complex workflow
3/ Decide to publish it
4/ Once it's publish it shows up
5/ Then you have tool too manage the result (delete, view stats, etc..)
The main difference with XWiki is the way you make the page show up on
the end site.
In a Wiki you are told to first create the link, then edit the page,
which makes the page show up right away. This makes the review part not
work at all.
Another difference is that you might want to be able to make a bit more
complex pages in a CMS (columns and so)
However the Blog is not that different from the CMS part, if we added
the review and more control of where the page shows up.
In a Blog you are very temporal. In a CMS you might not want the page to
show up in the Home page at all. You just want the page to show up where
you said it should show up.
I'm not sure if what you suggest is what you are saying. I think you are
more talking about the complex page issue.
On this matter we discussed this on a projet last friday where we need
columns in the page and we thought the Wysiwyg could handle columns.
It would be good to review what CMS do and integrate this nicely in
XWiki, as people more and more want to mix Publishing Web site with
collaborative ones.
Ludovic
Andreas Schaefer a écrit :
Hi
Currently our company is using Magnolia (magnolia.info) as the CMS for our website.
Because our website is not very dynamic, big or complex using Magnolia is often a little
bit of an overkill and keeping it up to date is not easy. So I was wondering if I could
use XWiki to create a simple application that would enable the creation and maintenance of
a website.
Today the Blog is a list of Blog Document building up the blog page. Breaking up the page
into a header, left and right side bar (or using the panels) and columns for the content
it should be possible to define a web page. The parts of a page a defined by classes and
the content is provided by objects. The application just provides the code that displays
the web site and additional elements to create, edit and remove parts of the document
(paragraphs) when the user is in edit mode.
The application would provide a simple web site but also the framework to create a custom
web site by extending the application.
What do you think?
Andreas Schaefer
CEO of Madplanet.com Inc.
EMail: andreas.schaefer(a)madplanet.com
schaefera(a)me.com
Twitter: andy_mpc
AIM: schaefera(a)me.com
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
19 Jul
19 Jul
11:20 a.m.
Hi,
Ludovic Dubost wrote:
Hi,
Indeed, XWiki is very close to a CMS and actually often used for this
(we use it for xwiki.com and xwiki.org).
When you look at it, most CMS work like this:
1/ Admin interface allowing to create a page, setup where it will show
up (on the home page, in a category menu, in a tag menu, in a Tree menu)
but not yet publish it
2/ Review with simple (most often) or more complex workflow
3/ Decide to publish it
I've been not able to give an answer to some people over here asking me
for a way of controlling/approving what/when pages are shown up.
Contents are related with human health issues, this this point is
extremely important: somebody have to have the responsibility of a
"final" OK for a given document. People is happy and feel themselves
comfortable with the way the "wiki way of doing things" keep control of
any and all changes, but they/we do need a way of approving a page for
publishing.
Please, has anybody faced a similar problem and solved it? Thanks!
Best regards,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
11:41 a.m.
Hi again,
[Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
Hi,
Ludovic Dubost wrote:
Please, allow to answer myself here with a different question, could
this entry posted by Guillaume in another thread be in the path to the
answer about workflow in XWiki?
--
I'm not sure we'll ever build a full-fledged workflow application in XWiki
Hi,
Indeed, XWiki is very close to a CMS and actually often used for this
(we use it for xwiki.com and xwiki.org).
When you look at it, most CMS work like this:
1/ Admin interface allowing to create a page, setup where it will show
up (on the home page, in a category menu, in a tag menu, in a Tree menu)
but not yet publish it
2/ Review with simple (most often) or more complex workflow
3/ Decide to publish it
I've been not able to give an answer to some people over here asking me
for a way of controlling/approving what/when pages are shown up.
Contents are related with human health issues, this this point is
extremely important: somebody have to have the responsibility of a
"final" OK for a given document. People is happy and feel themselves
comfortable with the way the "wiki way of doing things" keep control of
any and all changes, but they/we do need a way of approving a page for
publishing.
Please, has anybody faced a similar problem and solved it? Thanks!
Best regards,
Ricardo
but there are 2 things that can be done:
- Integrate XWiki with an external workflow engine such as Bonita
--
Thanks!
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
20 Jul
20 Jul
12:13 a.m.
[Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
Hi,
Ludovic Dubost wrote:
Well, a pretty simple solution is to use a Draft space, where guests
don't have view rights and all the registered users have edit rights,
and here people collaborate and create documents. When they consider
that a document is ready for the public, they let the admins know about
this, and one of the admins moves the document to its final destination,
where only admins can write.
This involves only a bit of access rights tweaking and the Rename menu
entry, without any complex tools or processes, but it assumes that
people are not evil and will respect the rules, which is usually true
inside a company.
To make things a bit more formal, there can be a second space called
Staging, which is the place where admins can look for documents ready to
become public, which eases the task of pointing out the documents to be
reviewed.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
Indeed, XWiki is very close to a CMS and actually often used for this
(we use it for xwiki.com and xwiki.org).
When you look at it, most CMS work like this:
1/ Admin interface allowing to create a page, setup where it will show
up (on the home page, in a category menu, in a tag menu, in a Tree menu)
but not yet publish it
2/ Review with simple (most often) or more complex workflow
3/ Decide to publish it
I've been not able to give an answer to some people over here asking me
for a way of controlling/approving what/when pages are shown up.
Contents are related with human health issues, this this point is
extremely important: somebody have to have the responsibility of a
"final" OK for a given document. People is happy and feel themselves
comfortable with the way the "wiki way of doing things" keep control of
any and all changes, but they/we do need a way of approving a page for
publishing.
Please, has anybody faced a similar problem and solved it? Thanks!
22 Jul
22 Jul
12:36 a.m.
Hi, Sergiu, thanks for the answer.
Sergiu Dumitriu wrote:
Well, a pretty simple solution is to use a Draft space, where guests
don't have view rights and all the registered users have edit rights,
and here people collaborate and create documents. When they consider
that a document is ready for the public, they let the admins know about
this, and one of the admins moves the document to its final destination,
where only admins can write.
I agree, this is straightforward.
This involves only a bit of access rights tweaking and
the Rename menu
entry, without any complex tools or processes, but it assumes that
people are not evil and will respect the rules, which is usually true
inside a company.
But evil could be in house.
And even though evil is not there we, human beings, are really bad at
following rules. Guided editing (something using a DTD, or a XML Schema
compliant document,...) could be the key.
Even more, there are legal constraints (something like HIPAA and/or HL7
) that forces us to have a "fine grained" publishing control system. It
is frequent to be required to control what document, or section of a
document, has been accessed or edited, when, by whom and from where. And
what document or part of a document will be published, when and who has
approved this action.
Integration of XWiki with other Open Source initiatives seems to be an
answer. For me the question here is if it is better to keep developing
XWiki in a given area, or to join another project as an alternative. For
instance, Pasca Voitot speaks in this same thread about the use of
Magnolia to provide a easily customizable front end for XWiki. The
result as he shows in his site Mandubian is quite good, but it seems to
me that XWiki skins are not so far of being able to allowing something
better!
It could be said that all these requirements could be only fulfilled by
a top-level commercial software. But we are in the Open Source side of
the moon! Why? This is the subject of a PhD dissertation :-)
As you say, XWiki apparently has all the required pieces to construct
such a system. I am trying to be as sure as possible that we are on the
right, or at least as right as possible, place.
In brief, we have not a full-featured publishing control system in XWiki
by now. But we do have a great framework and a great community! So,
let's go for it :-)
Thanks for your work. Greetings,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
8:23 a.m.
[Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
Hi, Sergiu, thanks for the answer.
Sergiu Dumitriu wrote:
One thing that should NOT be done, is to use different tools in
parallel. One of the big advantages of XWiki is that it allows to build
several application in the same place. True, such a small application
done with a piece of Velocity and a bit of JavaScript doesn't have all
the power and features of a dedicated system, but the advantages are
numerous:
- one place
- one UI
- one common set of rules
- one principle: the wiki way
- for the developers, one API and one common programming paradigm
- etc.
Well, a pretty simple solution is to use a Draft
space, where guests
don't have view rights and all the registered users have edit rights,
and here people collaborate and create documents. When they consider
that a document is ready for the public, they let the admins know about
this, and one of the admins moves the document to its final destination,
where only admins can write.
I agree, this is straightforward.
This involves only a bit of access rights
tweaking and the Rename menu
entry, without any complex tools or processes, but it assumes that
people are not evil and will respect the rules, which is usually true
inside a company.
But evil could be in house.
And even though evil is not there we, human beings, are really bad at
following rules. Guided editing (something using a DTD, or a XML Schema
compliant document,...) could be the key.
Even more, there are legal constraints (something like HIPAA and/or HL7
) that forces us to have a "fine grained" publishing control system. It
is frequent to be required to control what document, or section of a
document, has been accessed or edited, when, by whom and from where. And
what document or part of a document will be published, when and who has
approved this action.
Integration of XWiki with other Open Source initiatives seems to be an
answer. For me the question here is if it is better to keep developing
XWiki in a given area, or to join another project as an alternative. For
instance, Pasca Voitot speaks in this same thread about the use of
Magnolia to provide a easily customizable front end for XWiki. The
result as he shows in his site Mandubian is quite good, but it seems to
me that XWiki skins are not so far of being able to allowing something
better! It could be said that all these requirements could be
only fulfilled by
a top-level commercial software. But we are in the Open Source side of
the moon! Why? This is the subject of a PhD dissertation :-)
As you say, XWiki apparently has all the required pieces to construct
such a system. I am trying to be as sure as possible that we are on the
right, or at least as right as possible, place.
Hm, one thing I'd like to have before going forward with this app is a
better event management. The observation component is good, but we're
not using it enough. On top of it, we should build a workflow module.
Once we have this, writing a publishing control system should be easy.
At least a basic one, I don't know what those strange names you used
(HIPAA, HL7) imply.
About integrating with another tool, this is also a good idea, provided
that the tool provides nice APIs, and the tool is complex enough to make
a velocity replacement hard to implement.
In brief, we have not a full-featured publishing
control system in XWiki
by now. But we do have a great framework and a great community! So,
let's go for it :-)
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
9:10 a.m.
hello,
On Wed, Jul 22, 2009 at 8:23 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Please guys, don't use heavy orchestration industrial engines. I use them
all my days and there are really a pain, almost crazy. I can't understand
why people continue to go in this way just to design automaton with few
states and actions.
Pleaaaaaaaaaase don't do that ;)
[Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
One tool to rule them all etc... I have always been fighting against this
industrial way of thinking that tend to consider everything can go in the
same box... It sounds scary when someone tells me:"do NOT use other
tools"... But I see what you mean: using several tools that do the same
thing in parallel is not very good. But I prefer saying I use the best part
of each tools and make them fit together.
Hi, Sergiu, thanks for the answer.
Sergiu Dumitriu wrote:
One thing that should NOT be done, is to use different tools in
parallel. One of the big advantages of XWiki is that it allows to build
several application in the same place. True, such a small application
done with a piece of Velocity and a bit of JavaScript doesn't have all
the power and features of a dedicated system, but the advantages are
numerous:
- one place
- one UI
- one common set of rules
- one principle: the wiki way
- for the developers, one API and one common programming paradigm
- etc.
Well, a pretty simple solution is to use a Draft
space, where guests
don't have view rights and all the registered users have edit rights,
and here people collaborate and create documents. When they consider
that a document is ready for the public, they let the admins know about
this, and one of the admins moves the document to its final destination,
where only admins can write.
I agree, this is straightforward.
This involves only a bit of access rights
tweaking and the Rename menu
entry, without any complex tools or processes, but it assumes that
people are not evil and will respect the rules, which is usually true
inside a company.
But evil could be in house.
And even though evil is not there we, human beings, are really bad at
following rules. Guided editing (something using a DTD, or a XML Schema
compliant document,...) could be the key.
Even more, there are legal constraints (something like HIPAA and/or HL7
) that forces us to have a "fine grained" publishing control system. It
is frequent to be required to control what document, or section of a
document, has been accessed or edited, when, by whom and from where. And
what document or part of a document will be published, when and who has
approved this action.
Integration of XWiki with other Open Source initiatives seems to be an
answer. For me the question here is if it is better to keep developing
XWiki in a given area, or to join another project as an alternative. For
instance, Pasca Voitot speaks in this same thread about the use of
Magnolia to provide a easily customizable front end for XWiki. The
result as he shows in his site Mandubian is quite good, but it seems to
me that XWiki skins are not so far of being able to allowing something
better! From my point of view, I consider XWiki as a toolbox or
an enabler: it
allows me to do things I could never do alone because I would spend
too much
time gathering everything. But sometimes, I don't find what I need in XWiki
immediately and I don't have time to develop it completely, so I use another
tool and I distort the other tool and XWiki until they fit together.
This is not the solution for long term but it works. Moreover, it gives me
ideas about the "where" should go XWiki to fulfill such needs.
But, in fact, I really consider XWiki as an engine and I put the UI part
aside. I often need a content manager based on the XWiki features and then I
need to present this content. To my mind, the UI part of XWiki and the skin
should be separated as much as possible from XWiki (it is already the case)
and should be given some nice tools inspired by what can be found in other
tools for customizing skins.
It could be said that all these requirements
could be only fulfilled by
a top-level commercial software. But we are in the Open Source side of
the moon! Why? This is the subject of a PhD dissertation :-)
As you say, XWiki apparently has all the required pieces to construct
such a system. I am trying to be as sure as possible that we are on the
right, or at least as right as possible, place.
Hm, one thing I'd like to have before going forward with this app is a
better event management. The observation component is good, but we're
not using it enough. On top of it, we should build a workflow module.
Once we have this, writing a publishing control system should be easy.
At least a basic one, I don't know what those strange names you used
(HIPAA, HL7) imply.
About integrating with another tool, this is also a good idea, provided
that the tool provides nice APIs, and the tool is complex enough to make
a velocity replacement hard to implement.
In brief, we have not a full-featured publishing
control system in XWiki
by now. But we do have a great framework and a great community! So,
let's go for it :-)
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:58 p.m.
Pascal Voitot wrote:
hello,
On Wed, Jul 22, 2009 at 8:23 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Well, I didn't say not to use something, but not to use many similar
tools in parallel, when their functionality exists or can be easily
implemented in one place. And I don't say this as a marketing ploy for
XWiki, but with the users in mind.
[Ricardo Rodriguez] Your EPEC Network ICT Team
wrote:
One tool to rule them all etc... I have always been fighting against this
industrial way of thinking that tend to consider everything can go in the
same box... It sounds scary when someone tells me:"do NOT use other
tools"... But I see what you mean: using several tools that do the same
thing in parallel is not very good. But I prefer saying I use the best part
of each tools and make them fit together. Integration of XWiki with other Open Source
initiatives seems to be an
answer. For me the question here is if it is better to keep developing
XWiki in a given area, or to join another project as an alternative. For
instance, Pasca Voitot speaks in this same thread about the use of
Magnolia to provide a easily customizable front end for XWiki. The
result as he shows in his site Mandubian is quite good, but it seems to
me that XWiki skins are not so far of being able to allowing something
better!
One thing that should NOT be done, is to use different tools in
parallel. One of the big advantages of XWiki is that it allows to build
several application in the same place. True, such a small application
done with a piece of Velocity and a bit of JavaScript doesn't have all
the power and features of a dedicated system, but the advantages are
numerous:
- one place
- one UI
- one common set of rules
- one principle: the wiki way
- for the developers, one API and one common programming paradigm
- etc.
From my point of view, I consider XWiki as a toolbox
or an enabler: it
allows me to do things I could never do alone because I would spend too much
time gathering everything.
Yes, this is the main target, small apps that would take more to develop
standalone, but only a couple of hours inside XWiki.
But sometimes, I don't find what I need in XWiki
immediately and I don't have time to develop it completely, so I use another
tool and I distort the other tool and XWiki until they fit together.
This is not the solution for long term but it works. Moreover, it gives me
ideas about the "where" should go XWiki to fulfill such needs.
But, in fact, I really consider XWiki as an engine and I put the UI part
aside. I often need a content manager based on the XWiki features and then I
need to present this content. To my mind, the UI part of XWiki and the skin
should be separated as much as possible from XWiki (it is already the case)
and should be given some nice tools inspired by what can be found in other
tools for customizing skins.
Yes, we are aware of the skin customization problem, and we're planning
to improve this. But we're lacking manpower for it...
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
3:22 p.m.
Re Wiki vs CMS, Vincent did a nice presentation on the topic at the
beginning of the month:
http://massol.myxwiki.org/xwiki/bin/view/Blog/WikiVsCmsUsi2009
Guillaume
On Wed, Jul 22, 2009 at 2:58 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Pascal Voitot wrote:
One tool to rule them all etc... I have always been fighting against this
industrial way of thinking that tend to consider everything can go in the
same box... It sounds scary when someone tells me:"do NOT use other
tools"... But I see what you mean: using several tools that do the same
thing in parallel is not very good. But I prefer saying I use the best part
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
hello,
On Wed, Jul 22, 2009 at 8:23 AM, Sergiu Dumitriu <sergiu(a)xwiki.com>
wrote:
> [Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
>> Integration of XWiki with other Open Source initiatives seems to be an
>> answer. For me the question here is if it is better to keep developing
>> XWiki in a given area, or to join another project as an alternative.
For
instance, Pasca Voitot speaks in this same thread
about the use of
Magnolia to provide a easily customizable front end for XWiki. The
result as he shows in his site Mandubian is quite good, but it seems to
me that XWiki skins are not so far of being able to allowing something
better!
One thing that should NOT be done, is to use different tools in
parallel. One of the big advantages of XWiki is that it allows to build
several application in the same place. True, such a small application
done with a piece of Velocity and a bit of JavaScript doesn't have all
the power and features of a dedicated system, but the advantages are
numerous:
- one place
- one UI
- one common set of rules
- one principle: the wiki way
- for the developers, one API and one common programming paradigm
- etc.
of each tools and make them fit together.
Well, I didn't say not to use something, but not to use many similar
tools in parallel, when their functionality exists or can be easily
implemented in one place. And I don't say this as a marketing ploy for
XWiki, but with the users in mind.
From my point of view, I consider XWiki as a
toolbox or an enabler: it
allows me to do things I could never do alone because I would spend too
much
time gathering everything.
Yes, this is the main target, small apps that would take more to develop
standalone, but only a couple of hours inside XWiki.
But sometimes, I don't find what I need in
XWiki
immediately and I don't have time to develop it completely, so I use
another
tool and I distort the other tool and XWiki until
they fit together.
This is not the solution for long term but it works. Moreover, it gives
me
ideas about the "where" should go XWiki
to fulfill such needs.
But, in fact, I really consider XWiki as an engine and I put the UI part
aside. I often need a content manager based on the XWiki features and
then I
need to present this content. To my mind, the UI
part of XWiki and the
skin
should be separated as much as possible from
XWiki (it is already the
case)
and should be given some nice tools inspired by
what can be found in
other
tools for customizing skins.
Yes, we are aware of the skin customization problem, and we're planning
to improve this. But we're lacking manpower for it...
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
24 Jul
24 Jul
1:29 a.m.
Hi!
Pascal Voitot wrote:
Please, what are these "heavy orchestration industrial engines" you
propose to avoid? Thanks!
Best,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
Hm, one thing
I'd like to have before going forward with this app is a
better event management. The observation component is good, but we're
not using it enough. On top of it, we should build a workflow module.
Once we have this, writing a publishing control system should be easy.
At least a basic one, I don't know what those strange names you used
(HIPAA, HL7) imply.
About integrating with another tool, this is also a good idea, provided
that the tool provides nice APIs, and the tool is complex enough to make
a velocity replacement hard to implement.
Please guys, don't use heavy orchestration industrial engines. I use them
all my days and there are really a pain, almost crazy. I can't understand
why people continue to go in this way just to design automaton with few
states and actions.
Pleaaaaaaaaaase don't do that ;)
8:58 a.m.
On Fri, Jul 24, 2009 at 1:29 AM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> wrote:
Hi!
Pascal Voitot wrote:
Please, what are these "heavy orchestration industrial engines" you
propose to avoid? Thanks!
things like workflow engines such as jBPM, Bonita or even if we are crazier,
BPEL (I don't see why we could use BPEL here but I really think this is the
example of a technology that :) )... I don't say these engines are really
bad but they are too much complicated, too much theoretic, too heavy for a
simple workflow...
Hm, one
thing I'd like to have before going forward with this app is a
better event management. The observation component is good, but we're
not using it enough. On top of it, we should build a workflow module.
Once we have this, writing a publishing control system should be easy.
At least a basic one, I don't know what those strange names you used
(HIPAA, HL7) imply.
About integrating with another tool, this is also a good idea, provided
that the tool provides nice APIs, and the tool is complex enough to make
a velocity replacement hard to implement.
Please guys, don't use heavy orchestration industrial engines. I use them
all my days and there are really a pain, almost crazy. I can't understand
why people continue to go in this way just to design automaton with few
states and actions.
Pleaaaaaaaaaase don't do that ;)
Best,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:09 a.m.
Hi!
Pascal Voitot wrote:
things like workflow engines such as jBPM, Bonita or
even if we are crazier,
BPEL (I don't see why we could use BPEL here but I really think this is the
example of a technology that :) )... I don't say these engines are really
bad but they are too much complicated, too much theoretic, too heavy for a
simple workflow...
Thanks. I've been taking a look at Bonita and can, more or less,
understand what do you mean.
Thus, another doubt, why do these workflow engines exist? I mean, what
is the difference between the workflows we are speaking about and those
jBPM, Bonita or whatever engine you could know must face? Are they in an
alternative path or have these engines unnecessary complexity?
Thanks for your thoughts!
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
9:57 a.m.
On Fri, Jul 24, 2009 at 9:09 AM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> wrote:
Hi!
Pascal Voitot wrote:
I don't have a precise answer and I don't want to say stupid things because
I'm not exactly an expert at workflow design even if I use that often :)...
My feeling is that these technologies are born from the industrial server
movement... you know, a bit like J2EE servers... in a charicatural sentence,
I would say:"the bigger the better"... you take all the problems as a whole
and you provide a global solution for all problems... and then some people
say:"don't you think we could have something a bit more lightweight which
fulfills only what we need while keeping the possibility to use the big
server when we need it?"... and people find new ideas, concepts and designs
to make things more lightweight and you get things like Spring for example
(which is no more so lightweight anyway) and it makes change J2EE servers
because these ideas are not so stupid...
So now you take the great subject of automaton with states, workflows,
orchestrations, business process management and you create a tool allowing
to model any process corresponding to the theory, you participate to some
standardization meetings to make things a bit more abstract. Finally, you
get something powerful, huge, complex that can do everything you need but
also you don't need.
In fact, if you look carefully, these questions about process management are
almost everywhere in the industry but there are no good solutions. There are
some professional tools but they cost so much that you can't even imagine
paying that just to design a small publishing workflow...
BPM, BPM, BPM, BPM everywhere :)... I say that because it seems Business
Process Management is becoming a kind of holy grail for marketting people in
the software industry... but not sure technical people agree ;););)
Ok, that's all for now...
There are workflow engines in the opensource world but I don't know them
precisely so I can't say they are simpler or better...
This is my point of view from the industrial world :)
things like workflow engines such as jBPM, Bonita
or even if we are
crazier,
BPEL (I don't see why we could use BPEL here
but I really think this is
the
example of a technology that :) )... I don't
say these engines are
really
bad but they are too much complicated, too much
theoretic, too heavy for
a
simple workflow...
Thanks. I've been taking a look at Bonita and can, more or less,
understand what do you mean.
Thus, another doubt, why do these workflow engines exist? I mean, what
is the difference between the workflows we are speaking about and those
jBPM, Bonita or whatever engine you could know must face? Are they in an
alternative path or have these engines unnecessary complexity?
Thanks for your thoughts!
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
25 Jul
25 Jul
11:23 a.m.
Thank you for this point of view from the industrial world!
Before reading your answer I invested some time in browsing the
presentation done by Vincent and Tugduall Grall from eXo Platform (as
Guillaume pointed out in this same thread). First of all, I must
recognize that I didn't consider eXo as an option. I remember that more
than a year ago I tried to take a look at eXo, but I finally decide to
postpone this option: I was not able to understand how XWiki and eXo
interact. My fault!
Pascal, have you chosen Magnolia after comparing it with eXo? Or, have
you tried eXo?
Pascal Voitot wrote:
On Fri, Jul 24, 2009 at 9:09 AM, [Ricardo Rodriguez]
Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> wrote:
I don't have a precise answer and I don't want to say stupid things because
I'm not exactly an expert at workflow design even if I use that often :)...
My feeling is that these technologies are born from the industrial server
movement... you know, a bit like J2EE servers... in a charicatural sentence,
I would say:"the bigger the better"... you take all the problems as a whole
and you provide a global solution for all problems... and then some people
say:"don't you think we could have something a bit more lightweight which
fulfills only what we need while keeping the possibility to use the big
server when we need it?"... and people find new ideas, concepts and designs
to make things more lightweight and you get things like Spring for example
(which is no more so lightweight anyway) and it makes change J2EE servers
because these ideas are not so stupid...
So now you take the great subject of automaton with states, workflows,
orchestrations, business process management and you create a tool allowing
to model any process corresponding to the theory, you participate to some
standardization meetings to make things a bit more abstract. Finally, you
get something powerful, huge, complex that can do everything you need but
also you don't need.
In fact, if you look carefully, these questions about process management are
almost everywhere in the industry but there are no good solutions. There are
some professional tools but they cost so much that you can't even imagine
paying that just to design a small publishing workflow...
BPM, BPM, BPM, BPM everywhere :)... I say that because it seems Business
Process Management is becoming a kind of holy grail for marketting people in
the software industry... but not sure technical people agree ;););)
Ok, that's all for now...
Let's think about one of this huge initiatives facing a even bigger
problem. A number of vast firms establish a partnership, identify and
define the huge problem, devote a huge amount of resources and get their
solution. They must use this solution! Some people, being outside of the
partnership (auto-excluded or not being able to join it for one or other
reason) start thinking in this not so stupid way you talked about.
They/he/she act as the core of a new initiative to which, little by
little, new developers and users become involved with the initiative.
They become a team, trust each others, feel comfortable working together
and solve their day-by-day issues using a new via (Ok, ok, this could
sound a bit like Alicia's World, but if harmony, ethics and moral issues
are not applied here, I won't be able to explain what this happens!
Business are at the core, but they are not enough)
For me, for us, XWiki is one of this "not so stupid ideas" :-) And we
feel confortable working here. The answers that we are trying to answer
now are devoted to decide why we must keep trying to solve our "business
issues" with XWiki, team and software, at the core of our toolscape.
Of course we do realize that XWiki needs more resources to go further
and, mainly, developers could spend some less hours tied to their
computers! :-) Let's keep trying to do something useful.
In the last week, a number of Open Source initiatives has jumped in our
scenario as options to solve not-well-developed-yet XWiki issues (eXo,
Magnolia, Bonita, iText, jBPM,...)
Sergiu proposed a really simple way of solving the problem of
"publishing authorization". We need something a bit more complicated,
perhaps just facilitate that the responsible/responsibles of a document
receive a warning when the people involved with the creation of a
document agreed on its contents and that the publication of that
document will be effective when responsibles, let's say, check an
agreement box. I think this problem is far from needing any kind of
fancy workflow framework and can be solved within XWiki without much
work. We will keep an eye on any further development on integration with
other projects and try to finally update to 2.x and start contributing
to development.
There are workflow engines in the opensource world but
I don't know them
precisely so I can't say they are simpler or better...
This is my point of view from the industrial world :)
Thanks for your thoughts and your work!
Greetings,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
27 Jul
27 Jul
12:06 a.m.
On Sat, Jul 25, 2009 at 11:23 AM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> wrote:
Thank you for this point of view from the industrial
world!
Before reading your answer I invested some time in browsing the
presentation done by Vincent and Tugduall Grall from eXo Platform (as
Guillaume pointed out in this same thread). First of all, I must
recognize that I didn't consider eXo as an option. I remember that more
than a year ago I tried to take a look at eXo, but I finally decide to
postpone this option: I was not able to understand how XWiki and eXo
interact. My fault!
Pascal, have you chosen Magnolia after comparing it with eXo? Or, have
you tried eXo?
I did the same as you: just had a look at Exo... but Exo seems to be a full
enterprise platform... So as I wanted quickly just a skinning system to
integrate with XWiki, I chose among the solutions I knew and CMS were good
candidates. Then I chose a Java platform and finally I chose Magnolia after
some tries. I'm not really happy about Magnolia as the documentation is
really poor and the version I used was quite buggy but it allowed me to do
what I needed.
I should have a look at exo to see how it has evolved since.
Pascal Voitot wrote:
For me, for us, XWiki is one of this "not so stupid ideas" :-) And we
On Fri, Jul 24, 2009 at 9:09 AM, [Ricardo
Rodriguez] Your EPEC Network
ICT
Team <webmaster(a)environmentalchange.net>
wrote:
I don't have a precise answer and I don't want to say stupid things
because
I'm not exactly an expert at workflow design
even if I use that often
:)...
My feeling is that these technologies are born
from the industrial server
movement... you know, a bit like J2EE servers... in a charicatural
sentence,
I would say:"the bigger the better"...
you take all the problems as a
whole
and you provide a global solution for all
problems... and then some
people
say:"don't you think we could have
something a bit more lightweight which
fulfills only what we need while keeping the possibility to use the big
server when we need it?"... and people find new ideas, concepts and
designs
to make things more lightweight and you get
things like Spring for
example
(which is no more so lightweight anyway) and it
makes change J2EE servers
because these ideas are not so stupid...
So now you take the great subject of automaton with states, workflows,
orchestrations, business process management and you create a tool
allowing
to model any process corresponding to the theory,
you participate to some
standardization meetings to make things a bit more abstract. Finally, you
get something powerful, huge, complex that can do everything you need but
also you don't need.
In fact, if you look carefully, these questions about process management
are
almost everywhere in the industry but there are
no good solutions. There
are
some professional tools but they cost so much
that you can't even imagine
paying that just to design a small publishing workflow...
BPM, BPM, BPM, BPM everywhere :)... I say that because it seems Business
Process Management is becoming a kind of holy grail for marketting people
in
the software industry... but not sure technical
people agree ;););)
Ok, that's all for now...
Let's think about one of this huge initiatives facing a even bigger
problem. A number of vast firms establish a partnership, identify and
define the huge problem, devote a huge amount of resources and get their
solution. They must use this solution! Some people, being outside of the
partnership (auto-excluded or not being able to join it for one or other
reason) start thinking in this not so stupid way you talked about.
They/he/she act as the core of a new initiative to which, little by
little, new developers and users become involved with the initiative.
They become a team, trust each others, feel comfortable working together
and solve their day-by-day issues using a new via (Ok, ok, this could
sound a bit like Alicia's World, but if harmony, ethics and moral issues
are not applied here, I won't be able to explain what this happens!
Business are at the core, but they are not enough)
feel confortable working here. The answers that we are
trying to answer
now are devoted to decide why we must keep trying to solve our "business
issues" with XWiki, team and software, at the core of our toolscape.
I really agree with you. In my case, I can tell you that I chose XWiki after
trying many other solutions and it appears to be the best solution for my
problems in the open source world... I use XWiki not just for fun or because
it's opensource but because it really fits my needs!
Of course we do realize that XWiki needs more resources to go further
and, mainly, developers could spend some less hours tied to their
computers! :-) Let's keep trying to do something useful.
In the last week, a number of Open Source initiatives has jumped in our
scenario as options to solve not-well-developed-yet XWiki issues (eXo,
Magnolia, Bonita, iText, jBPM,...)
I'm not sure all of these are really useful for XWiki :)
Sergiu proposed a really simple way of solving the
problem of
"publishing authorization". We need something a bit more complicated,
perhaps just facilitate that the responsible/responsibles of a document
receive a warning when the people involved with the creation of a
document agreed on its contents and that the publication of that
document will be effective when responsibles, let's say, check an
agreement box. I think this problem is far from needing any kind of
fancy workflow framework and can be solved within XWiki without much
work. We will keep an eye on any further development on integration with
other projects and try to finally update to 2.x and start contributing
to development.
There are
workflow engines in the opensource world but I don't know them
precisely so I can't say they are simpler or better...
This is my point of view from the industrial world :)
Thanks for your thoughts and your work!
Greetings,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:50 a.m.
Pascal Voitot wrote:
On Sat, Jul 25, 2009 at 11:23 AM, [Ricardo Rodriguez]
Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> wrote:
I really agree with you. In my case, I can tell you that I chose XWiki after
trying many other solutions and it appears to be the best solution for my
problems in the open source world... I use XWiki not just for fun or because
it's opensource but because it really fits my needs!
And, in the proprietary software world, what are the comparison points
for you? Thanks!
Greetings!
--
Ricardo Rodríguez
Your EPEC Network ICT Team
7:31 a.m.
On Mon, Jul 27, 2009 at 12:50 AM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> wrote:
Pascal Voitot wrote:
On Sat, Jul 25, 2009 at 11:23 AM, [Ricardo
Rodriguez] Your EPEC Network
ICT
Team <webmaster(a)environmentalchange.net>
wrote:
I really agree with you. In my case, I can tell you that I chose XWiki
after
trying many other solutions and it appears to be
the best solution for my
problems in the open source world... I use XWiki not just for fun or
because
it's opensource but because it really fits my
needs!
And, in the proprietary software world, what are the comparison points
for you? Thanks!
Greetings!
--
Ricardo Rodríguez
Your EPEC Network ICT Team
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:48 a.m.
On Mon, Jul 27, 2009 at 12:50 AM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> wrote:
Pascal Voitot wrote:
sorry for my last empty mail... clicked too quick...
I think about Sharepoint for example... this is the first answer you get
when dealing with content management in companies where office networks
already run on Microsoft technos...
I should have a look at it to have some arguments to say this might not be
the best solution... apparently it can mix content with structured data as
XWiki can do with classes/objects... Anyone knows about it?
regards
Pascal
On Sat, Jul 25, 2009 at 11:23 AM, [Ricardo
Rodriguez] Your EPEC Network
ICT
Team <webmaster(a)environmentalchange.net>
wrote:
I really agree with you. In my case, I can tell you that I chose XWiki
after
trying many other solutions and it appears to be
the best solution for my
problems in the open source world... I use XWiki not just for fun or
because
it's opensource but because it really fits my
needs!
And, in the proprietary software world, what are the comparison points
for you? Thanks!
Greetings!
--
Ricardo Rodríguez
Your EPEC Network ICT Team
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:37 p.m.
Pascal Voitot wrote:
sorry for my last empty mail... clicked too quick...
I think about Sharepoint for example... this is the first answer you get
when dealing with content management in companies where office networks
already run on Microsoft technos...
I should have a look at it to have some arguments to say this might not be
the best solution... apparently it can mix content with structured data as
XWiki can do with classes/objects... Anyone knows about it?
Sorry, Pascal, I don't understand what content does mean here. Are not
strutured data content? Won't be better to say something like
"apparently it can mix structured and unstructured data" being
"content"
reserved for the whole "thing"? And I don't understand the comparison
with the use of classes/objects in XWiki.
Do you thing to put an example is worth here?
I am struggling to navigate in the structured data/documents world and
getting the right terminology. After only a few weeks back in an old
path I've abandoned for more than a year, I think that what we are
looking for here is a on-line/off-line Schema-Guided Document-Editing
Interface (Schema being here DTD, XML Schema, or whatever other language
developed to describe XML schemas). To be able to decide if XWiki would
be the framework for such an objective will be of a great help!
Best,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
6:56 p.m.
2009/7/27 [Ricardo Rodriguez] Your EPEC Network ICT Team <
webmaster(a)environmentalchange.net>
Pascal Voitot wrote:
Yes this is exactly what I mean... you can mix some structured data and
unstructured also...
In my mind, classes/objects in XWiki are the structured data and the
classical Wiki content is the "unstructured" data...
sorry for my last empty mail... clicked too
quick...
I think about Sharepoint for example... this is the first answer you get
when dealing with content management in companies where office networks
already run on Microsoft technos...
I should have a look at it to have some arguments to say this might not
be
the best solution... apparently it can mix
content with structured data
as
XWiki can do with classes/objects... Anyone knows
about it?
Sorry, Pascal, I don't understand what content does mean here. Are not
strutured data content? Won't be better to say something like
"apparently it can mix structured and unstructured data" being
"content"
reserved for the whole "thing"? And I don't understand the comparison
with the use of classes/objects in XWiki.
Do you thing to put an example is worth here?
I can't give an example as I don't have sharepoint :)
I am struggling to navigate in the structured data/documents world and
getting the right terminology. After only a few weeks back in an old
path I've abandoned for more than a year, I think that what we are
looking for here is a on-line/off-line Schema-Guided Document-Editing
Interface (Schema being here DTD, XML Schema, or whatever other language
developed to describe XML schemas). To be able to decide if XWiki would
be the framework for such an objective will be of a great help!
Don't understand what you mean with your XML Schemas? Do you want to
represent your structured data with schemas?
Best,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:10 p.m.
Pascal Voitot wrote:
Yes this is exactly what I mean... you can mix some structured data and
unstructured also...
In my mind, classes/objects in XWiki are the structured data and the
classical Wiki content is the "unstructured" data...
OK. I've got the point.
Don't understand what you mean with your XML
Schemas? Do you want to
represent your structured data with schemas?
Yeap. Consider this schema wroten in XML Schema language
http://examples.oreilly.com/xmlschema/examples/first.xsd
It is possible/it is feasible to be possible working with XWiki to guide
the edition of documents complying with this schema?
I am sure I am missing a lot of subtle and no so subtle issues here. But
I am trying to be as precise as possible. I've been working for Adobe
FrameMaker for years, but never got the point of structural enforcement.
I am trying now to regain access to this issue and to understand how
XWiki could fit with this task. Adobe FrameMaker is a great tool. I
missed it a lot! But it could be one of this "huge" tools that is much
bigger than the problem we are facing right now. If XWiki can
grow/develop in this direction, we will devote our efforts to solve our
needs with it.
Sorry for not being able to be clearer!
Cheers,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
8:47 p.m.
On Mon, Jul 27, 2009 at 8:10 PM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> wrote:
Pascal Voitot wrote:
I'm not the guy to give you any answer but I'm interested in this idea...
What do you mean exactly by "guide the edition complying with this schema"?
Should it be just metadata associated with the doc or should the doc follow
a template based on this schema or is it a kind a form associated to the
document?
Yes this is exactly what I mean... you can mix some structured data and
unstructured also...
In my mind, classes/objects in XWiki are the structured data and the
classical Wiki content is the "unstructured" data...
OK. I've got the point.
Don't understand what you mean with your XML
Schemas? Do you want to
represent your structured data with schemas?
Yeap. Consider this schema wroten in XML Schema language
http://examples.oreilly.com/xmlschema/examples/first.xsd
It is possible/it is feasible to be possible working with XWiki to guide
the edition of documents complying with this schema?
I am sure I am missing a lot of subtle and no so subtle issues here. But
I am trying to be as precise as possible. I've been working for Adobe
FrameMaker for years, but never got the point of structural enforcement.
I am trying now to regain access to this issue and to understand how
XWiki could fit with this task. Adobe FrameMaker is a great tool. I
missed it a lot! But it could be one of this "huge" tools that is much
bigger than the problem we are facing right now. If XWiki can
grow/develop in this direction, we will devote our efforts to solve our
needs with it.
Sorry for not being able to be clearer!
Cheers,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
28 Jul
28 Jul
1:47 p.m.
Pascal Voitot wrote
I'm not the guy to give you any answer but I'm
interested in this idea...
What do you mean exactly by "guide the edition complying with this schema"?
Should it be just metadata associated with the doc or should the doc follow
a template based on this schema or is it a kind a form associated to the
document?
Great to hear than anybody else thinks that this could be a "no so
stupid idea" It is a pity that the idea is not mine :-)
Any document must follow the rules or grammar set in the schema. A
really simple example. Thing about an scientific paper, or a business
report, or a medical history. We could define a common set of features
to each "family" of documents. For instance, it is commonly accepted
that a scientific paper must content at least a summary, an
introduction, material and methods, results discussion and bibliography.
Introduction usually content a number of paragraphs, but no tables, no
images, no lists. Results could content tables and/or pictures.
Bibliography, a list of references. This structure could be described by
an schema, whatever language is used for that.
What I am looking for is to know how long, or close, is XWiki to be able
to guide de edition of a new document belonging to one of this "families".
DocBook is a much more complex schema suited to write books and papers
about computer hardware and software.
Of course there is a whole universe out there dealing with this topics.
The question here is of XWiki is, or has the possibility of being, able
to be one of this "no so stupid" ideas that will ease the path to
start-ups not needing the whole complexity of SGML/XML driven, or
guided, editing.
Looking at the new rendering module (general architecture)...
http://code.xwiki.org/xwiki/bin/view/Modules/RenderingModule
... there are a number of supported syntaxes listed there. Parsers for
each syntax will, optionally, generate a XDOM object suitable for
transformations and that will be the entry for the renderers. My guess
is that it will be possible to use a given parser at entry time. It
probably won't be be called a parser in this case! The point is to have
a tool that, in a given document, only allow entries complying with the
rules/grammar defined in a given schema (again, whatever language is
used to write it).
I would not like to mess up things here. I am far from having a clear
idea about the field I am talking about. But at the same time, I do need
to talk with somebody/read more and more to clear up things! So, please,
excuse me if these posts are not plenty or erudition. And, please, don't
hesitate to tell me if this not the right place to post about this.
Thanks for your time,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
2:03 p.m.
Hi Ricardo,
On Tue, Jul 28, 2009 at 1:47 PM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> wrote:
Pascal Voitot wrote
Not sure that's what you're looking for (since you're talking language +
grammar), but there might be a simple way to create this in XWiki using
XClasses & XObjects. Basically you would have to define a set of classes and
then write some code to make them display together nicely:
- One ScientificPaperClass with the following string properties:
summary, introduction,
materialAndMethods, resultsDiscussion, bibliography + metadata associated to
the paper: authors, date, topic, etc...
- ScientificPaperClassSheet where you can edit those metadata fields +
select the relevant pages for each section
- A SummaryClass + an IntroductionClass + a ParagraphClass
- On the SummaryClassSheet and the IntroductionClassSheet, you add a
button allowing the user to add only ParagraphClass XObjects to
an instance
of the SummaryClass or IntroductionClass page
- A MaterialsAndMethodsClass and a ResultsDiscussionClass + ImageClass,
TableClass, ReferenceClass each of which holds the metadata related to the
item (author, date, source etc)
- On pages using one of those 2 classes, make buttons available (add
Text, add an Image, add a Table, add a Reference) to add various types of
content to them
- You generate the bibliography automatically from ReferenceClass
XObjects available in the ScientificPaperClass composite document
This short specification isn't perfect, but you get the geist of it.
This means that the whole authoring tool would much more structured than
only using a specific language + grammar, but it would allow for a guided
edition process that would remain simple enough. We've actually been working
on a similar project for one of our customers and it seems to be working
fine for them.
Would that way of doing things suit your use case?
Guillaume
Ricardo
I'm not the guy to give you any answer but
I'm interested in this idea...
What do you mean exactly by "guide the edition complying with this
schema"?
Should it be just metadata associated with the
doc or should the doc
follow
a template based on this schema or is it a kind a
form associated to the
document?
Great to hear than anybody else thinks that this could be a "no so
stupid idea" It is a pity that the idea is not mine :-)
Any document must follow the rules or grammar set in the schema. A
really simple example. Thing about an scientific paper, or a business
report, or a medical history. We could define a common set of features
to each "family" of documents. For instance, it is commonly accepted
that a scientific paper must content at least a summary, an
introduction, material and methods, results discussion and bibliography.
Introduction usually content a number of paragraphs, but no tables, no
images, no lists. Results could content tables and/or pictures.
Bibliography, a list of references. This structure could be described by
an schema, whatever language is used for that.
What I am looking for is to know how long, or close, is XWiki to be able
to guide de edition of a new document belonging to one of this "families".
DocBook is a much more complex schema suited to write books and papers
about computer hardware and software.
Of course there is a whole universe out there dealing with this topics.
The question here is of XWiki is, or has the possibility of being, able
to be one of this "no so stupid" ideas that will ease the path to
start-ups not needing the whole complexity of SGML/XML driven, or
guided, editing.
Looking at the new rendering module (general architecture)...
http://code.xwiki.org/xwiki/bin/view/Modules/RenderingModule
... there are a number of supported syntaxes listed there. Parsers for
each syntax will, optionally, generate a XDOM object suitable for
transformations and that will be the entry for the renderers. My guess
is that it will be possible to use a given parser at entry time. It
probably won't be be called a parser in this case! The point is to have
a tool that, in a given document, only allow entries complying with the
rules/grammar defined in a given schema (again, whatever language is
used to write it).
I would not like to mess up things here. I am far from having a clear
idea about the field I am talking about. But at the same time, I do need
to talk with somebody/read more and more to clear up things! So, please,
excuse me if these posts are not plenty or erudition. And, please, don't
hesitate to tell me if this not the right place to post about this.
Thanks for your time,
--
Ricardo Rodríguez
Your EPEC Network ICT Team
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
2:14 p.m.
hello,
On Tue, Jul 28, 2009 at 2:03 PM, Guillaume Lerouge <guillaume(a)xwiki.com>wrote;wrote:
Hi Ricardo,
On Tue, Jul 28, 2009 at 1:47 PM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> wrote:
the
"families".
This is an implementation solution (one I've already used and that works
pretty cool)
The idea of the schema would certainly be also to manage this construction
in an automatic manner... That's certainly the question behind this...
Ricardo, am I right?
Pascal Voitot wrote
> I'm not the guy to give you any answer but I'm interested in this
idea...
What do
you mean exactly by "guide the edition complying with this
schema"?
Should it be just metadata associated with the
doc or should the doc
follow
> a template based on this schema or is it a kind a form associated to
document?
Great to hear than anybody else thinks that this could be a "no so
stupid idea" It is a pity that the idea is not mine :-)
Any document must follow the rules or grammar set in the schema. A
really simple example. Thing about an scientific paper, or a business
report, or a medical history. We could define a common set of features
to each "family" of documents. For instance, it is commonly accepted
that a scientific paper must content at least a summary, an
introduction, material and methods, results discussion and bibliography.
Introduction usually content a number of paragraphs, but no tables, no
images, no lists. Results could content tables and/or pictures.
Bibliography, a list of references. This structure could be described by
an schema, whatever language is used for that.
What I am looking for is to know how long, or close, is XWiki to be able
to guide de edition of a new document belonging to one of this
DocBook is a much more complex schema suited to write books and papers
about computer hardware and software.
Of course there is a whole universe out there dealing with this topics.
The question here is of XWiki is, or has the possibility of being, able
to be one of this "no so stupid" ideas that will ease the path to
start-ups not needing the whole complexity of SGML/XML driven, or
guided, editing.
Looking at the new rendering module (general architecture)...
http://code.xwiki.org/xwiki/bin/view/Modules/RenderingModule
... there are a number of supported syntaxes listed there. Parsers for
each syntax will, optionally, generate a XDOM object suitable for
transformations and that will be the entry for the renderers. My guess
is that it will be possible to use a given parser at entry time. It
probably won't be be called a parser in this case! The point is to have
a tool that, in a given document, only allow entries complying with the
rules/grammar defined in a given schema (again, whatever language is
used to write it).
I would not like to mess up things here. I am far from having a clear
idea about the field I am talking about. But at the same time, I do need
to talk with somebody/read more and more to clear up things! So, please,
excuse me if these posts are not plenty or erudition. And, please, don't
hesitate to tell me if this not the right place to post about this.
Thanks for your time,
Not sure that's what you're looking for (since you're talking language +
grammar), but there might be a simple way to create this in XWiki using
XClasses & XObjects. Basically you would have to define a set of classes
and
then write some code to make them display together nicely:
- One ScientificPaperClass with the following string properties:
summary, introduction,
materialAndMethods, resultsDiscussion, bibliography + metadata associated
to
the paper: authors, date, topic, etc...
- ScientificPaperClassSheet where you can edit those metadata fields +
select the relevant pages for each section
- A SummaryClass + an IntroductionClass + a ParagraphClass
- On the SummaryClassSheet and the IntroductionClassSheet, you add a
button allowing the user to add only ParagraphClass XObjects to
an instance
of the SummaryClass or IntroductionClass page
- A MaterialsAndMethodsClass and a ResultsDiscussionClass + ImageClass,
TableClass, ReferenceClass each of which holds the metadata related to
the
item (author, date, source etc)
- On pages using one of those 2 classes, make buttons available (add
Text, add an Image, add a Table, add a Reference) to add various types
of
content to them
- You generate the bibliography automatically from ReferenceClass
XObjects available in the ScientificPaperClass composite document
This short specification isn't perfect, but you get the geist of it.
This means that the whole authoring tool would much more structured than
only using a specific language + grammar, but it would allow for a guided
edition process that would remain simple enough. We've actually been
working
on a similar project for one of our customers and it seems to be working
fine for them.
Would that way of doing things suit your use case?
Guillaume
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:02 p.m.
Guillaume, Pascal, thanks for the answers!
Pascal Voitot wrote:
>
> Would that way of doing things suit your use case?
>
>
Thanks, Guillaume. Yes, this could suit a particular case, but...
This is an implementation solution (one I've
already used and that works
pretty cool)
The idea of the schema would certainly be also to manage this construction
in an automatic manner... That's certainly the question behind this...
Ricardo, am I right?
... as Pascal said and you yourself has pointed out, this is an
implementation case.
To use XWiki classes/objects/attributes to hold document nodes and their
content will be nice option, but the point here is the be able to use de
schema to drive the add hoc creation of these "elements", thus to guide
de edition of a given document.
I hardly find the right words/concepts to explain the idea (nothing
fancy, but I am a bit loss in the XML jungle!), but I think the
combination of your two last messages give the clue of it.
By taken a look to the survey Guillaume sent a couple of minutes ago, I
found "Document Type Manager". I don't know what is the idea behind the
title, but I guess it could be related with what we are speaking about
at some extent.
Thanks for your thoughts,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
24 Jul
24 Jul
1:54 a.m.
Hi,
Sorry for using acronyms without not decoding them.
Sergiu Dumitriu wrote:
Hm, one thing I'd like to have before going
forward with this app is a
better event management. The observation component is good, but we're
not using it enough. On top of it, we should build a workflow module.
Once we have this, writing a publishing control system should be easy.
At least a basic one, I don't know what those strange names you used
(HIPAA, HL7) imply.
*HIPAA* stands for "Health Insurance Portability and Accountability Act"
For instance, on *HIPAA Privacy*
"The Privacy Rule provides federal protections for personal health
information held by covered entities and gives patients an array of
rights with respect to that information. At the same time, the Privacy
Rule is balanced so that it permits the disclosure of personal health
information needed for patient care and other important purposes."
If we use an XWiki instance to store/manage this kind of information, we
must know how to fulfill these requirements.
*HL7* stands for "Health Level Seven". It is an all-volunteer,
not-for-profit organization involved in development of international
healthcare standards (from Wikipedia).
For instance, does make sense to use XWiki to produce HL7 Clinical
Document Architecture (CDA) compliant documents?
In a more general way, is it possible to use XWiki to "host"/develop a
guided editing environment? I guess the answer will be YES! :-) Thus, I
must go on with the second part of the question... how! :-)
All the best,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
20 Jul
20 Jul
10:14 p.m.
Hello,
Here is my experience.
For my simple technical website (www.mandubian.org (not ads here)), I used a
mix between Magnolia and XWiki:
- Magnolia as the content aggregator and "visual facade" using Magnolia
easily customisable skin system, publishing/workflow features and also for
the idea of authoring/public instances. But I don't need anything more from
Magnolia.
- XWiki as the content provider with a small plugin I developed in order to
integrate XWiki into Magnolia. XWiki provides a much simpler and concrete
way to create my content because my website is not a commercial site or
sport news site.
In a summary, I write with XWiki and I publish with Magnolia.
So everything is not perfect and well integrated but it works and I can
publish my small articles quite easily.
In fact, beyond some publishing and workflow features that XWiki lacks, the
reason why I chose to use Magnolia CMS for the "what you see" and XWiki for
the "what you get" is the skin issue: I can't spend too much time
customizing the skin and I need a "practical" base for this:
- a nice skin with all the stuff a website usually provides (menus, teasers,
panels, events, columns, etc...)
- A wysiwyg way to modify the skin and re-organize the structure of the
presentation
Magnolia (and other CMS) provides it. XWiki provides everything to do it but
not "out of the box" and you need to customize everything manually. I
customized XWiki skin for some sites focused on the "Wiki" features but for
a public website, this consumes too much time.
You guys at XWiki must be in the middle of the now classical CMS/Wiki
conflict but I used some CMS for some time now and XWiki for some time also
and my conclusion is that I don't see any reason why XWiki couldn't be used
to create nice websites.
regards
Pascal
On Sat, Jul 18, 2009 at 11:35 AM, Ludovic Dubost <ludovic(a)xwiki.org> wrote:
Hi,
Indeed, XWiki is very close to a CMS and actually often used for this
(we use it for xwiki.com and xwiki.org).
When you look at it, most CMS work like this:
1/ Admin interface allowing to create a page, setup where it will show
up (on the home page, in a category menu, in a tag menu, in a Tree menu)
but not yet publish it
2/ Review with simple (most often) or more complex workflow
3/ Decide to publish it
4/ Once it's publish it shows up
5/ Then you have tool too manage the result (delete, view stats, etc..)
The main difference with XWiki is the way you make the page show up on
the end site.
In a Wiki you are told to first create the link, then edit the page,
which makes the page show up right away. This makes the review part not
work at all.
Another difference is that you might want to be able to make a bit more
complex pages in a CMS (columns and so)
However the Blog is not that different from the CMS part, if we added
the review and more control of where the page shows up.
In a Blog you are very temporal. In a CMS you might not want the page to
show up in the Home page at all. You just want the page to show up where
you said it should show up.
I'm not sure if what you suggest is what you are saying. I think you are
more talking about the complex page issue.
On this matter we discussed this on a projet last friday where we need
columns in the page and we thought the Wysiwyg could handle columns.
It would be good to review what CMS do and integrate this nicely in
XWiki, as people more and more want to mix Publishing Web site with
collaborative ones.
Ludovic
Andreas Schaefer a écrit :
Hi
Currently our company is using Magnolia (magnolia.info) as the CMS for
our
website. Because our website is not very dynamic, big or complex using
Magnolia is often a little bit of an overkill and keeping it up to date is
not easy. So I was wondering if I could use XWiki to create a simple
application that would enable the creation and maintenance of a website.
Today the Blog is a list of Blog Document building up the blog page.
Breaking up
the page into a header, left and right side bar (or using the
panels) and columns for the content it should be possible to define a web
page. The parts of a page a defined by classes and the content is provided
by objects. The application just provides the code that displays the web
site and additional elements to create, edit and remove parts of the
document (paragraphs) when the user is in edit mode.
The application would provide a simple web site but also the framework to
create a
custom web site by extending the application.
What do you think?
Andreas Schaefer
CEO of Madplanet.com Inc.
EMail: andreas.schaefer(a)madplanet.com
schaefera(a)me.com
Twitter: andy_mpc
AIM: schaefera(a)me.com
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
22 Jul
22 Jul
12:51 a.m.
Hi!
Pascal Voitot wrote:
Hello,
Here is my experience.
For my simple technical website (www.mandubian.org (not ads here)), I used a
mix between Magnolia and XWiki:
Your site looks nice!
- Magnolia as the content aggregator and "visual
facade" using Magnolia
easily customisable skin system, publishing/workflow features and also for
the idea of authoring/public instances. But I don't need anything more from
Magnolia.
So, it seems that it is worth to invest some efforts to improve and/or
ease the skin customization application. I don't know who is actually
working in this issue, but I remember a lot of messages about the topic.
Don't you think that it is worth to invest some time/resources in
developing such an application?
You guys at XWiki must be in the middle of the now
classical CMS/Wiki
conflict but I used some CMS for some time now and XWiki for some time also
and my conclusion is that I don't see any reason why XWiki couldn't be used
to create nice websites.
I am not sure if this is right terms of the discussion. Is it possible
to compare a CMS with XWiki? I don't know if it is possible to compare a
CMS with other wikis, but XWiki is, if I've well understood, about using
the wiki concept to develop applications, no contents. Contents are of
course an important part of the system. Thus, publishing control and
guided edition could be killer applications.
XWiki has its own channels for proposals, so it is my responsibility to
try to write something with sense and sher it!
Mandubian is now in my bookmarks toolbar!
Greetings,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
9:50 a.m.
On Wed, Jul 22, 2009 at 12:51 AM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> wrote:
yes it is worth...
I don't know who works on that now as I'm not in XWiki team but I think this
might take some time also.
Moreover, the question is: what is a good skin customization tool? (keeping
current flexible features around velocity and giving a nice wysiwyg way of
structuring your skin)...
In a summary, in magnolia, as everything is stored in JCR, everything is a
tree and then the skin is a tree. They mix this tree structure with the
templating approach. So you build your skin from the top to the bottom:
parts embedding other parts embedding other parts etc... And you can say: in
this part, I can accept only this and this and this. Then they have a kind
of MVC model to represent each part and the rendering part is managed with
the templating engine FreeMarker (velocity like).
So it is quite easy to change the skin structure.
Finally what's nice with their tool is that when you are working on your
site, you have a quick view of it and every content in it is enhanced by a
small toolbox allowing to edit, move, delete it... with that, you can
reorganize the page in a WYSIWYG way. I want this teaser to go before this
one, I want to add a new paragraph just here, to change this header or
footer here, to change the title etc... almost inline editing... not perfect
but quite practical...
Not the same approach as the wiki approach but with the xwiki wysiwyg
editor, we go in this way.
I really like the idea of changing the site from the site itself. (No I
don't want to have dreamweaver, just some features of it ;););) )
And something I like in CMS: you have an authoring instance and a public
instance of your site. You play in the authoring instance until you are
happy and then you publish from the authoring instance into the public
instance...
Yes it is possible to compare and lots of people do it all the time and even
fight against each other... "I'm for CMS"... "I'm for WIKI"...
this is the
WCM, the "war for content management"... everyone wants the business of the
other one..
I prefer working on their convergence in the domains in which they can
converge...
Hi!
Pascal Voitot wrote:
thks ;)
Hello,
Here is my experience.
For my simple technical website (www.mandubian.org (not ads here)), I
used a
mix between Magnolia and XWiki:
Your site looks nice! - Magnolia as the content aggregator and
"visual facade" using Magnolia
easily customisable skin system, publishing/workflow features and also
for
the idea of authoring/public instances. But I
don't need anything more
from
Magnolia.
So, it seems that it is worth to invest some efforts to improve and/or
ease the skin customization application. I don't know who is actually
working in this issue, but I remember a lot of messages about the topic.
Don't you think that it is worth to invest some time/resources in
developing such an application? You guys at XWiki must be in the middle of the
now classical CMS/Wiki
conflict but I used some CMS for some time now and XWiki for some time
also
and my conclusion is that I don't see any
reason why XWiki couldn't be
used
to create nice websites.
I am not sure if this is right terms of the discussion. Is it possible
to compare a CMS with XWiki? I don't know if it is possible to compare a
CMS with other wikis, but XWiki is, if I've well understood, about using
the wiki concept to develop applications, no contents. Contents are of
course an important part of the system. Thus, publishing control and
guided edition could be killer applications.
XWiki has its own channels for proposals, so it is my responsibility to
try to write something with sense and sher it!
Mandubian is now in my bookmarks toolbar!
Keep it ;)
Don't be surprised when it seems down, this is a private server and I
perform some experience sometimes...
Greetings,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
24 Jul
24 Jul
1:14 a.m.
Hi, Pascal,
I'am still catching up with the XWiki 2.0. I can more or less understand
what you are saying about Magnolia, JCR, MVC and the CMS
authoring/public pair (I've seen this in OpenCMS, but I am not sure this
is also truth in Joomla, for instance), but I've not been able yet of
having an in depth look to the new XWiki 2.0 and its brand new WYSIWYG
editor. In fact, I keep using the XWiki edition mode. I guess there are
a lot of new features concerning skin customization in this new release
but it is possible there are not documented yet.
Also, there is an open project, XWiki Skin Extensions,
http://jira.xwiki.org/jira/browse/XSKINX, devoted to convert the skin
extension module intro a proper component.
Have you seen this...
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Skins
Cheers,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
1:26 a.m.
hello
On Fri, Jul 24, 2009 at 1:14 AM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> wrote:
Hi, Pascal,
I'am still catching up with the XWiki 2.0. I can more or less understand
what you are saying about Magnolia, JCR, MVC and the CMS
authoring/public pair (I've seen this in OpenCMS, but I am not sure this
is also truth in Joomla, for instance), but I've not been able yet of
having an in depth look to the new XWiki 2.0 and its brand new WYSIWYG
editor. In fact, I keep using the XWiki edition mode. I guess there are
a lot of new features concerning skin customization in this new release
but it is possible there are not documented yet.
Also, there is an open project, XWiki Skin Extensions,
http://jira.xwiki.org/jira/browse/XSKINX, devoted to convert the skin
extension module intro a proper component.
Have you seen this...
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Skins
Yes I have seen this...
As I said, you can customize everything you want in XWiki, even the skin...
but it is not quite easy without lots of scripting and CSS-styling etc...
And what's interesting in Drupal, Joomla or Magnolia is that you can easily
find skin templates on the web with all the UI components needed to build a
website and there are also modules that allow to customize graphically the
look&feel of your website. Generally I Don't want to spend too much time on
skin design when I begin a new web project... I want to focus on the
content, not on the skin...
Pascal
Cheers,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:13 a.m.
Hi!
Pascal Voitot wrote:
Yes I have seen this...
As I said, you can customize everything you want in XWiki, even the skin...
but it is not quite easy without lots of scripting and CSS-styling etc...
And what's interesting in Drupal, Joomla or Magnolia is that you can easily
find skin templates on the web with all the UI components needed to build a
website and there are also modules that allow to customize graphically the
look&feel of your website. Generally I Don't want to spend too much time on
skin design when I begin a new web project... I want to focus on the
content, not on the skin...
I get your point. But until I see your site done with Magnolia+XWiki, I
thought that it is really possible to identify a site done with Drupal
or Joomla, by the look of the "customized" skins done by using the
customization wizards of this systems.
OK, XWiki has not such kind of tool, but I think I do prefer a clear and
complete documentation that can be understood by a design team to be
appointed to develop a completely different look and feel over a WYSIWYG
wizard allowing, probably, only some actions.
I am sure, with an enlarged dev team, none of these will be a problem!
Cheers,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
9:06 a.m.
On Fri, Jul 24, 2009 at 2:13 AM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> wrote:
Hi!
Pascal Voitot wrote:
yes generally, you can see that :)
My aim was just to have a quick facade looking like a complete site, not
like a wiki or a blog and then I wanted to keep XWiki as the content
provider.
Yes I have seen this...
As I said, you can customize everything you want in XWiki, even the
skin...
but it is not quite easy without lots of
scripting and CSS-styling etc...
And what's interesting in Drupal, Joomla or Magnolia is that you can
easily
find skin templates on the web with all the UI
components needed to build
a
website and there are also modules that allow to
customize graphically
the
look&feel of your website. Generally I
Don't want to spend too much time
on
skin design when I begin a new web project... I
want to focus on the
content, not on the skin...
I get your point. But until I see your site done with Magnolia+XWiki, I
thought that it is really possible to identify a site done with Drupal
or Joomla, by the look of the "customized" skins done by using the
customization wizards of this systems.
OK, XWiki has not such kind of tool, but I think I do prefer a clear and
complete documentation that can be understood by a design team to be
appointed to develop a completely different look and feel over a WYSIWYG
wizard allowing, probably, only some actions.
the wysiwyg should only be a helper allowing to access some features more
easily but we need to keep the deep customization features (the XWiki
wysiwyg editor is an example of that... you can write with it but when you
need to have a more precise view, you go in the classical editor)
I am sure, with an enlarged dev team, none of these will be a problem!
for sure, this wouldn't be a problem ;)...
Imagine you have a project with a quotation of 1.000.000 mendays... you find
1.000.000 people and in 1 day, you have your solution :)
Cheers,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
25 Jul
25 Jul
12:01 p.m.
Hi!
Pascal Voitot wrote:
the wysiwyg should only be a helper allowing to access
some features more
easily but we need to keep the deep customization features (the XWiki
wysiwyg editor is an example of that... you can write with it but when you
need to have a more precise view, you go in the classical editor)
I agree with
that! But I think this was not true with the old XWiki wiki
editor: switching between wiki and WYSIWYG editors results in losses
and/or changes in the format and, as far as I can remember, even
contents (changes in code that result in changes in displayed content).
I guess this is not longer true with the new WYSIWYG included with 2.x.
We are looking for enjoying it.
for sure, this wouldn't be a problem ;)...
Imagine you have a project with a quotation of 1.000.000 mendays... you find
1.000.000 people and in 1 day, you have your solution :)
Wait! We must change a concept here! We can not use man-day. We could
use person-day or people-days! My wife is involved in genre equality
policies and teaches me on this issues.
Greetings!
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
26 Jul
26 Jul
11:25 p.m.
On Sat, Jul 25, 2009 at 12:01 PM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> wrote:
You would be right in a humanistic world but in ours, companies policies
more and more teach me to speak about "cattle-days" :):)... and tell to your
wife not to care about equality because women or men are quite equal with
respect to this way of thinking: you're just a resource with a cost, nothing
less, nothing more ;)
Hi!
Pascal Voitot wrote:
you're right, the new GWT editor is really greater than the previous editor!
still some small bugs but really better!
the wysiwyg should only be a helper allowing to
access some features more
easily but we need to keep the deep customization features (the XWiki
wysiwyg editor is an example of that... you can write with it but when
you
need to have a more precise view, you go in the
classical editor)
I agree with that! But I think this was not true with the old
XWiki wiki
editor: switching between wiki and WYSIWYG editors results in losses
and/or changes in the format and, as far as I can remember, even
contents (changes in code that result in changes in displayed content).
I guess this is not longer true with the new WYSIWYG included with 2.x.
We are looking for enjoying it. for sure, this wouldn't be a problem ;)...
Imagine you have a project with a quotation of 1.000.000 mendays... you
find
1.000.000 people and in 1 day, you have your
solution :)
Wait! We must change a concept here! We can not use man-day. We could
use person-day or people-days! My wife is involved in genre equality
policies and teaches me on this issues.
Greetings!
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
27 Jul
27 Jul
12:55 a.m.
Pascal Voitot wrote:
You would be right in a humanistic world but in ours,
companies policies
more and more teach me to speak about "cattle-days" :):)... and tell to your
wife not to care about equality because women or men are quite equal with
respect to this way of thinking: you're just a resource with a cost, nothing
less, nothing more ;)
I am sure to be a woman or to be a man is not an issue on
this list, or
in the XWiki project as a whole! But perhaps you know cases where the
cost of the human resource depends, at some extent, on gender. If you
don't, those are great news!
Greetings,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
7:38 a.m.
On Mon, Jul 27, 2009 at 12:55 AM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> wrote:
Pascal Voitot wrote:
Sorry guy, yes I know one... football ;)
And I really hope this is not an issue to be a man or woman for XWiki
:):):)... We are all equal and humble regarding XWiki, aren't we?
And anyway, XWiki contains only X chromosom in its name, no Y so I would
tend to say it might be more a product for women than for men ;););)
You would be right in a humanistic world but in
ours, companies policies
more and more teach me to speak about "cattle-days" :):)... and tell to
your
wife not to care about equality because women or
men are quite equal with
respect to this way of thinking: you're just a resource with a cost,
nothing
less, nothing more ;)
I am sure to be a
woman or to be a man is not an issue on this list, or
in the XWiki project as a whole! But perhaps you know cases where the
cost of the human resource depends, at some extent, on gender. If you
don't, those are great news!
Greetings,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:43 a.m.
Hi!
Pascal Voitot wrote:
> Sorry guy, yes I know one... football ;)
> And I really hope this is not an issue to be a man or woman for XWiki
> :):):)... We are all equal and humble regarding XWiki, aren't we?
> And anyway, XWiki contains only X chromosom in its name, no Y so I would
> tend to say it might be more a product for women than for men ;););)
:-)
As this list is not the right place for small talk, I think that we must
move the discussion about football and chromosomes to any more
interesting place... perhaps some cold beer will ease the chat. I feel
myself more and more comfortable here. After all, ecosystems and
chromosomes are, or have been, my work topics for years!
Cheers,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
10:34 a.m.
On Mon, Jul 27, 2009 at 9:43 AM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <webmaster(a)environmentalchange.net> wrote:
Hi!
Pascal Voitot wrote:
you're right, this is not twitter here ;)
anyway, we can enjoy a bit before going back to our lifes of resources ;)
> Sorry guy, yes I know one... football ;)
> And I really hope this is not an issue to be a man or woman for XWiki
> :):):)... We are all equal and humble regarding XWiki, aren't we?
> And anyway, XWiki contains only X chromosom in its name, no Y so I would
> tend to say it might be more a product for women than for men ;););)
:-)
As this list is not the right place for small talk, I think that we must
move the discussion about football and chromosomes to any more
interesting place... perhaps some cold beer will ease the chat. I feel
myself more and more comfortable here. After all, ecosystems and
chromosomes are, or have been, my work topics for years!
Cheers,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5529
days inactive
5539
days old
40 comments
6 participants
participants (6)
-
[Ricardo Rodriguez] Your EPEC Network ICT Team -
Andreas Schaefer -
Guillaume Lerouge -
Ludovic Dubost -
Pascal Voitot -
Sergiu Dumitriu