[xwiki-devs] XWiki as simle Web Site Platform
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: [email protected] [email protected] Twitter: andy_mpc AIM: [email protected]
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: [email protected] [email protected] Twitter: andy_mpc AIM: [email protected] _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
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
Hi again, [Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
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
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
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
[Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
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!
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, 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
[Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
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!
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.
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/
hello, On Wed, Jul 22, 2009 at 8:23 AM, Sergiu Dumitriu <[email protected]> wrote:
[Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
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!
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.
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.
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.
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 ;)
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Pascal Voitot wrote:
hello,
On Wed, Jul 22, 2009 at 8:23 AM, Sergiu Dumitriu <[email protected]> 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.
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.
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/
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 <[email protected]> wrote:
Pascal Voitot wrote:
hello,
On Wed, Jul 22, 2009 at 8:23 AM, Sergiu Dumitriu <[email protected]> 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.
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.
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Hi! Pascal Voitot 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.
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 ;)
Please, what are these "heavy orchestration industrial engines" you propose to avoid? Thanks! Best, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team
On Fri, Jul 24, 2009 at 1:29 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> wrote:
Hi!
Pascal Voitot 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.
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 ;)
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...
Best,
Ricardo
-- Ricardo Rodríguez Your EPEC Network ICT Team
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
On Fri, Jul 24, 2009 at 9:09 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> wrote:
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?
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 :)
Thanks for your thoughts!
Ricardo
-- Ricardo Rodríguez Your EPEC Network ICT Team
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 <[email protected]> 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
On Sat, Jul 25, 2009 at 11:23 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> 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:
On Fri, Jul 24, 2009 at 9:09 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> 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.
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Pascal Voitot wrote:
On Sat, Jul 25, 2009 at 11:23 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> 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
On Mon, Jul 27, 2009 at 12:50 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> wrote:
Pascal Voitot wrote:
On Sat, Jul 25, 2009 at 11:23 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Jul 27, 2009 at 12:50 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> wrote:
Pascal Voitot wrote:
On Sat, Jul 25, 2009 at 11:23 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> 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!
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
-- Ricardo Rodríguez Your EPEC Network ICT Team
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
2009/7/27 [Ricardo Rodriguez] Your EPEC Network ICT Team < [email protected]>
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.
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...
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
On Mon, Jul 27, 2009 at 8:10 PM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> wrote:
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.
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?
Sorry for not being able to be clearer!
Cheers,
Ricardo
-- Ricardo Rodríguez Your EPEC Network ICT Team
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
Hi Ricardo, On Tue, Jul 28, 2009 at 1:47 PM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> 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?
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,
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
hello, On Tue, Jul 28, 2009 at 2:03 PM, Guillaume Lerouge <[email protected]>wrote:
Hi Ricardo,
On Tue, Jul 28, 2009 at 1:47 PM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> 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?
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,
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?
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?
Guillaume
Ricardo
-- Ricardo Rodríguez Your EPEC Network ICT Team
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
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
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 <[email protected]> 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: [email protected] [email protected] Twitter: andy_mpc AIM: [email protected] _______________________________________________ devs mailing list [email protected] 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
On Wed, Jul 22, 2009 at 12:51 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> wrote:
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!
thks ;)
- 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?
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...
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.
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...
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
hello On Fri, Jul 24, 2009 at 1:14 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> 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...
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
On Fri, Jul 24, 2009 at 2:13 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> wrote:
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.
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.
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
On Sat, Jul 25, 2009 at 12:01 PM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> wrote:
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.
you're right, the new GWT editor is really greater than the previous editor! still some small bugs but really better!
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.
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 ;)
Greetings!
Ricardo
-- Ricardo Rodríguez Your EPEC Network ICT Team
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
On Mon, Jul 27, 2009 at 12:55 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> wrote:
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!
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 ;););)
Greetings,
Ricardo
-- Ricardo Rodríguez Your EPEC Network ICT Team
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
On Mon, Jul 27, 2009 at 9:43 AM, [Ricardo Rodriguez] Your EPEC Network ICT Team <[email protected]> wrote:
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!
you're right, this is not twitter here ;) anyway, we can enjoy a bit before going back to our lifes of resources ;)
Cheers,
Ricardo
-- Ricardo Rodríguez Your EPEC Network ICT Team
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (6)
-
[Ricardo Rodriguez] Your EPEC Network ICT Team -
Andreas Schaefer -
Guillaume Lerouge -
Ludovic Dubost -
Pascal Voitot -
Sergiu Dumitriu