Dan Murphy wrote:
Sorry about that... finger trouble !
It seems that with the exception of the few obvious name clashes we
can just
go ahead and create pages. If later we discover a clash then we will
need to
change the page name accordingly. Assuming you use the normal wiki link
markup cwiki fixes the link changes.
Where their is an obvious cross area topic/chapter we can just prefix the
page name with something appropriate... a couple of examples:
The "Introduction" for the "SCA in Java User Guide" would become "SCA
Java
User - Introduction"...
The "Introduction" for the "SCA in CPP Developer Guide" would become "SCA
CPP Dev - Introduction"...
Most page names are unique enough. For example "Obtaining Tuscany's
Java SCA
Implementation" is a user guide document (currently) but the name is
unique
enough not to worry about prefixing it... and besides it might also want
including elsewhere.
So, as general guidance, if we write a document with a name that is
obviously going to clash with another in a different domain... prefix
it....
otherwise don't bother.
There is a minor "bummer" about prefixing, but it only effects us if
we use
some of the macros (we can't avoid having the prefix visible)... but this
seems a minor concern given the complexity of multiple spaces. I had
stopped
writing (pending a "conclusion" on this thread), but now I'm going to get
back to it...
WDYT ?
On 13/02/07, Dan Murphy <[EMAIL PROTECTED]> wrote:
Hi,
In line with what Simon put above, it would seem sensible to try to
prefix
pages (as setting up extra spaces for a lowish number of pages does seem
like an overhead)
So... for SCA Java specific pages we prefix the page name with "SCA
Java"
Topic
On 11/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 2/10/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
> >
> > Ah. You add a good point that we need to think about extension
> documents
> > as
> > well :)
> >
> > On 2/9/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
> > >
> > > On Feb 9, 2007, at 4:56 PM, haleh mahbod wrote:
> > > > "Extension developer would generally not work off the latest
code
> (I
> > > > generally discourage people from doing this as the state of
trunk
> may
> > > > be in flux). They would tend to go off a published release."
> > > >
> > > > OK. Although it seems like all discussions are typically
centered
>
> > > > around
> > > > the latest code on mailing list.
> > > > Maybe this is what we should encourage.
> > >
> > > When you munge everything together it can be hard to tell. Most of
> > > the technical discussion recently has been around changes to the
> > > kernel rather than extensions and so naturally relates to the
latest
> > > kernel code. If we did have discussion around an extension, it
would
>
> > > be about the latest code /of that extension/.
> > >
> > > --
> > > Jeremy
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> So, from this thread, a number of things that partition our
> documentation.
>
> Underlying technology: Java, C++
> Project: SCA, SDO, DAS
> Module(?): Kernel, Runtimes, Extensions...
> Release: M1, M2, M3 (are the next releases going to be at the module
> level
> now?)
> Reader: User, Extension Developer, Developer
>
> It seems that the Cwiki is shaping up as follows:
>
> SCA
> Java
> User pages
> Intro
> Installing
> Samples
> Building an app
> What extension are available
> Etc…
> Developer pages
> Intro
> Architecture
> Dev env
> Module docs
> Etc…
> C++
> FAQ - not sure why this is at this level?
> SDO
> Java
> C++
> FAQ
> DAS
> Java
> C++
> FAQ
>
> It's difficult to comment on whether developer docs should be separate
> from
> extension developer docs but if feels like it's a low priority at the
> moment. We should make space to describe the separate modules that are
> available both from user and developer perspectives.
>
> Is there still going to be a full milestone release at some point
where
> documentation is built or are the separate modules going to advance
> independently? This will flavor how we keep track of what we are
writing
> docs for. As we are still in incubation can we continue just to worry
> about
> the latest code? I like the idea of using new spaces to represent
> documentation for major releases but that doesn't work for finer
grained
> releases. We need a way of marking which details relate to which
> version.
> Confluence themselves label pages, e.g, (
> http://confluence.atlassian.com/display/DOC/Administrators+Guide),
but I
> don't know how they use the labels exactly yet.
>
> As Dan pointed out page names must be unique within a space but this
> doesn't
> cause particular pain in our PHP site as we just prefix page names. We
> do
> have a very small number of pages though. We also use the Left
> Navigation
> theme. This provides a left hand menu like they have on CFX (
> http://cwiki.apache.org/CXF/) as Shelita noted. Changing the theme
is a
> space admin task.
If the wiki was switched to a "left menu theme" it would probably apply
to the whole space.
That would not work well for Tuscany since it has 3 separate projects
(sca, sdo, das) as well as 2 implementations (java, cpp).
i.e. the site is very complicated and it wouldn't be worth it to carry
that left menu everywhere. There is always the
horizontal link navigation at the top of every page anyway so a user is
only one click from the top page.
I just added a left-hand-nav to the wiki homepage to serve as a TOC.
It's pretty simple.
I tried to follow the existing Tuscany home as much as possible, and
link to new information on the wiki as well.
If the team agrees with this approach, we can migrate useful information
off of the existing homepage
and onto the wiki. If the team doesn't think this is the way to go,
its a simple "undo".
I'm willing to port some of the existing pages over and update them in
the process if this helps.
If we want this is Ted Husted the man to talk to? Does
>
> anyone from Tuscany have space admin privileges?
I think that all commiters have space admin privilege.
See http://cwiki.apache.org/CWIKI/ and look for "Give the
$project-committers groups all rights to the Space."
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
