22 Jul
2009
22 Jul
'09
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