9 Sep
2007
9 Sep
'07
9:03 p.m.
On Sep 9, 2007, at 8:34 PM, Erin Schnabel wrote:
On 9/9/07, Vincent Massol <vincent(a)massol.net>
wrote:
I really dislike the monolithic "Panels" xar. The Panels xar should
contain only the Panels app/Panels Wizard, IMO. The other panels
(navigation, search, blah blah) should be closer to the xar's that
contain similar function... especially as the panels macros are in the
default template set...
Good point. I agree that the XARs should be segmented by features and
not by "technology".
As you say we'll still have some base Panel docs (templates, classes,
classheets, etc). They can go either in a Panel XAR or in the Admin
XAR. Being in the Admin means there's no other way than the Panels
for menus which is true now but probably won't in the future. Also if
that Panel XAR is not installed then installing, say, the Blog
feature which has the Blog Panel will make the Blog Panel not work.
But we can probably still have that provided we implement application
dependencies (a la Maven).
For now we could have the Panels base docs in the Admin XAR and each
Panel in the application XAR corresponding to its domain. This will
ensure the base panels classes are always present.
-Vincent
On Sep 9, 2007, at 11:22 AM, Thomas Mortagne wrote:
[snip..]
Yes
it's that, for now. I suppose latter we will have more template
(Blog wiki, Wiki wiki, ...).
Yes that's a very good idea. Once we have separated XE into
applications we could have the following XARs:
- Blog
- Search
- Admin
- Panels
- Navigation
- Photo Album
- etc
Actually I
think we could go a step further for all applications,
templates, etc. I envision an online XWiki repository of
applications, plugins, templates, etc, and in the admin part of XE or
XEM you'll be able to see all of them ,see whether they are already
installed or not and if not, have the option to install them.
I think this is even nicer and offer more capabilities than a static
installer.
Thanks
-Vincent
>>> 2007/9/6, Vincent Massol <vincent(a)massol.net>et>:
>>>> Hi,
>>>>
>>>> I'm proposing to improve the generic install to add database
>>>> configuration setup:
>>>>
>>>> 1) include different database driver jars in the installer
>>>> 2) have some installation panels to let the user choose the
>>>> database
>>>> to use (using some combo box and fields to modify default DB
>>>> values)
>>>> 3) include the XAR in the installer
>>>> 4) use the packager tool to import the XAR in the database at
>>>> install
>>>> time (using the information provided in 2))
>>>>
>>>> Note: I'd also like to modify the web/standard build so that we
>>>> release only a single WAR without database driver and without DB
>>>> configuration.
>>>>
>>>> Advanced users will configure it manually and novice will use the
>>>> installer.
>>>>
>>>> WDYT?
>>>>
>>>> Thanks
>>>> -Vincent
This is how I manage my customized install:
I have one xar containing the "only do this if you're doing a fresh
install" pages, like XWikiPreferences, for example. You have to
assume that after a clean install, XWikiPreferences will have been
customized.
Then I have a second xar for those things I modified that should be
updated to refresh/upgrade an existing install: Search page changes,
or updates to the XWikiUserSheet-- things that aren't likely to be
customized, but that would be updated as part of a new/upgraded
release.
then I have other xars for the applications I use and maintain, like
the "Packager" application from the CodeZone (which I've modified).
It allows me to use a text box (primitive) to specify the list of
pages to include in each of these xars, and to specify a version for
that xar, so I end up with: custom-tool-1.5.xar. Each of the
individual xar files contains a "Package" page, so that I know what
version I updated last. I should probably package that up w/ my
changes and send it to you guys, eh?
I'd also like to see (and perhaps you're implying this, Vincent) the
XWikiPreferences and Skins pages simplified. Having all of the
different *.vm fields, plus all of the other gorp is pretty busy.
Seems like that one big monolithic object could be split into more
pieces. For example, it's assumed that you have an ad client id...
wouldn't it be better to have the ad stuff as a separate object that
can be added to the Preferences page if you have ads? Same with all of
the macro pages.. Can't we have smaller objects that manage the groovy
settings, and the velocity settings?