XWiki as simle Web Site Platform

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

XWiki as simle Web Site Platform

Andreas Schaefer
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: [hidden email]
           [hidden email]
Twitter: andy_mpc
AIM:     [hidden email]
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

Ludovic Dubost-2

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: [hidden email]
>            [hidden email]
> Twitter: andy_mpc
> AIM:     [hidden email]
> _______________________________________________
> devs mailing list
> [hidden email]
> 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

rrodrigueznt
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

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

rrodrigueznt
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

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

Sergiu Dumitriu-2
In reply to this post by rrodrigueznt
[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/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

Pascal Voitot
In reply to this post by Ludovic Dubost-2
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 <[hidden email]> 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: [hidden email]
> >            [hidden email]
> > Twitter: andy_mpc
> > AIM:     [hidden email]
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

rrodrigueznt
In reply to this post by Sergiu Dumitriu-2
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

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

rrodrigueznt
In reply to this post by Pascal Voitot
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

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

Sergiu Dumitriu-2
In reply to this post by rrodrigueznt
[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/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

Pascal Voitot
hello,

On Wed, Jul 22, 2009 at 8:23 AM, Sergiu Dumitriu <[hidden email]> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

Pascal Voitot
In reply to this post by rrodrigueznt
On Wed, Jul 22, 2009 at 12:51 AM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <[hidden email]> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

Sergiu Dumitriu-2
In reply to this post by Pascal Voitot
Pascal Voitot wrote:

> hello,
>
> On Wed, Jul 22, 2009 at 8:23 AM, Sergiu Dumitriu <[hidden email]> 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

Guillaume Lerouge
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 <[hidden email]> wrote:

> Pascal Voitot wrote:
> > hello,
> >
> > On Wed, Jul 22, 2009 at 8:23 AM, Sergiu Dumitriu <[hidden email]>
> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

rrodrigueznt
In reply to this post by Pascal Voitot
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

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

Pascal Voitot
hello

On Fri, Jul 24, 2009 at 1:14 AM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <[hidden email]> wrote:

> Hi, Pascal,
>
> I'am still catching up with the XWiki 2.0. I can more or less understand
> what you are saying about Magnolia, JCR, MVC and the CMS
> authoring/public pair (I've seen this in OpenCMS, but I am not sure this
> is also truth in Joomla, for instance), but I've not been able yet of
> having an in depth look to the new XWiki 2.0 and its brand new WYSIWYG
> editor. In fact, I keep using the XWiki edition mode. I guess there are
> a lot of new features concerning skin customization in this new release
> but it is possible there are not documented yet.
>
> Also, there is an open project, XWiki Skin Extensions,
> http://jira.xwiki.org/jira/browse/XSKINX, devoted to convert the skin
> extension module intro a proper component.
>
> Have you seen this...
>
> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Skins
>

Yes I have seen this...
As I said, you can customize everything you want in XWiki, even the skin...
but it is not quite easy without lots of scripting and CSS-styling etc...
And what's interesting in Drupal, Joomla or Magnolia is that you can easily
find skin templates on the web with all the UI components needed to build a
website and there are also modules that allow to customize graphically the
look&feel of your website. Generally I Don't want to spend too much time on
skin design when I begin a new web project... I want to focus on the
content, not on the skin...


Pascal



>
> Cheers,
>
> Ricardo
>
> --
> Ricardo Rodríguez
> Your EPEC Network ICT Team
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

rrodrigueznt
In reply to this post by Pascal Voitot
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

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

rrodrigueznt
In reply to this post by Sergiu Dumitriu-2
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

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

rrodrigueznt
In reply to this post by Pascal Voitot
Hi!

Pascal Voitot wrote:

>> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Skins
>>
>>    
>
> Yes I have seen this...
> As I said, you can customize everything you want in XWiki, even the skin...
> but it is not quite easy without lots of scripting and CSS-styling etc...
> And what's interesting in Drupal, Joomla or Magnolia is that you can easily
> find skin templates on the web with all the UI components needed to build a
> website and there are also modules that allow to customize graphically the
> look&feel of your website. Generally I Don't want to spend too much time on
> skin design when I begin a new web project... I want to focus on the
> content, not on the skin...
>  

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

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

Pascal Voitot
In reply to this post by rrodrigueznt
On Fri, Jul 24, 2009 at 1:29 AM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <[hidden email]> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: XWiki as simle Web Site Platform

Pascal Voitot
In reply to this post by rrodrigueznt
On Fri, Jul 24, 2009 at 2:13 AM, [Ricardo Rodriguez] Your EPEC Network ICT
Team <[hidden email]> wrote:

> Hi!
>
> Pascal Voitot wrote:
> >> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Skins
> >>
> >>
> >
> > Yes I have seen this...
> > As I said, you can customize everything you want in XWiki, even the
> skin...
> > but it is not quite easy without lots of scripting and CSS-styling etc...
> > And what's interesting in Drupal, Joomla or Magnolia is that you can
> easily
> > find skin templates on the web with all the UI components needed to build
> a
> > website and there are also modules that allow to customize graphically
> the
> > look&feel of your website. Generally I Don't want to spend too much time
> on
> > skin design when I begin a new web project... I want to focus on the
> > content, not on the skin...
> >
>
> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
123