The future of Scarab ... !?! ...

Hi.

While i am at it i might just set up a new "letter of intent". Here we go:

* The Scarab Reporting submodule *

I propose to cleanly separate the reporting part of Scarab from the Issue
handling part. I have been working mainly on the core issue-editing module
of Scarab during the last 2 years while completely neglecting the reporting
part at all. So i even do not know if i have introduced bugs there or if it
even remains functional. 

Since the reporting part in my eyes always was sort of wage buggy and clumsy
to maintain and use, i propose to:

1.) add a way to disable/enable the reporting module by configuration.
2.) disable the module by default
3.) concentrate on the core features of Scarab (issue tracking)
4.) Develop a clean API for external reporting tools.
5.) implement a "poor man's reporting tool" for proof of concept of the
reporting-API

Note that this is NOT my primary goal on Scarab. Its just a proposal of how
to deal with the reporting system in the future.

* The Scarab user interface (skins)*

Currently i have prepared Scarab for skinning. My development version is
technically able to support multiple skins at the same time. I was able to
implement that with astonishingly small changes of the core velocity
templates. The default "skin" still contains Scarab's "old fashioned look
and feel" with some very decent changes mainly due to better structural
definition of the screen layout. Indeed it will be possible to support
multiple style sheets at the same time and users may eventually be able to
individually choose among several "display styles" (aka "skins") (Only the
control buttons are still missing on the GUI). 

* The Scarab poor man's clients *

In principle you can maintain sets of alternate velocity templates. I have
added some support for this mainly to be able to change the structural
layout of Scarab (which is currently "baked" into the templates). In
principle you can tell Scarab to "use another set of templates with a fall
back to the default". In more detail you can modify any of the existing
templates and even add new ones. But instead of replacing the default
templates and thus permanently changing Scarab's behavior, you can place the
alternative files into a "client" directory. Scarab will first search the
client-directory and only switch back to the default directory, if the
client does not contain the template. Of course you can explicitly tell
Scarab to use a client-setup or the default setup. This is done through the
URL.

One nice side effect of this ability is that the customization of Scarab
will get easier and more fail proof. e.g.  instead of maintaining a set of
user extensions which will affect Scarab on its whole, you now can setup an
alternate skin, place your modifications into that skin and have the Scarab
default AND your changes side by side. So if you messed up something in your
skin, you can switch back to the default by one click...

This is not pure theory. Indeed we USE it on a production system in order to
allow a different setup of the standard query page for anonymous users
compared to the query page shown to logged in users. Messing with the
templates and adding if-then-else stuff there was very! inconvenient
compared to just setup a secnd client-folder (containing only one modified
template!)...

* More on layout *

I have held back our proposal for Scarab's new Look and feel until the
skin-support is fully developed. Now we are shortly before check in to
trunk. So i will prepare Scarab to distribute "the old default look and
feel" plus the new "web-2.0 look and feel" side by side. You will be able to
switch between the 2 either on the user level or hard customized through the
Scarab properties.

"web-2.0 look and feel" implies (on the long run) some significant changes
on the web frontend. I strongly want to add a javascript based framework in
order to  introduce some of the nicer gimicks on the frontend especially for
improved display options. Scarab is way out of "state of the art" on the GUI
side. (well we could argue here that it is "non state of the art" in its
entirety ... i will not go into depth here ;-)
I think prototype or Jquery are the candidates (Jquery is cooler i think)
...

* More on customization *

I hate to rebuild Scarab in order to change the email templates! ...
I think, customization should be taken to "another level"... well, not
making it even more complex, but allowing for more flexibility AND make it
easier to customize. The email template is just one example. Actually the
first issue i plan to make customizable from an admin-page in Scarab...
Other will certainly follow... Like extended l10n suport also for customized
fields. I always found it hard to work with a fully supported l10n System on
one side then not be able to maintain l10n for field labels... (and this
idea is at least 5 years old now)

So long that's what currently spins in my mind. And there is even more. But
i'd say one step after the other. At the end we will stick again with a
discussion whether Scarab should be fully rewritten...
-- 
View this message in context: http://old.nabble.com/The-future-of-Scarab-...-%21-%21-...-tp28340270p28340270.html
Sent from the Scarab - Dev mailing list archive at Nabble.com.

------------------------------------------------------
http://scarab.tigris.org/ds/viewMessage.do?dsForumId=455&dsMessageId=2593428

To unsubscribe from this discussion, e-mail: [[email protected]].