On Tue, Jun 19, 2001 at 02:26:59PM +0300, Jyry Kuukkanen wrote:
> On Tue, 19 Jun 2001, Tomas V.V.Cox wrote:
>
> > Hi people,
> >
> > Another idea about this topic and to bypass the tired task of writing
> > the same stuff twice (one for the X and other for the Web), the system
> > could be built over some kind of open intercommunication platform like
> > Corba or XML-RPC.
> >
> > Just some ideas. Regards,
> >
> > Tomas V.V.Cox
>
>
> Hello
>
>
> There has been discussion on which dbase to used and of which type.
> Tomas's point is more that important for more than one reason.
>
>
> Let me coin in couple of thoughts.
>
> Wouldn't it make more sense to break this project into three sections:
>
> 1) User interface related (web/Local GUI/...)
> 2) Application functions (create project, allocate resourses etc.)
> 3) Database connectivity
He, you seem to be a programmer ;)
That is a standard programming model, where a programmer builds the
parts seperately so its a lot easier to bugfix and build new front-ends.
The default would be to have it like this
1) internal data model. A number of classes that represent the different
things (where things are everything from a project to a user to
a contractor)
2) build saving loading and interactions INTO the data objects. I.e.
a project can save itself as an xml-stream. Just a stream, someone
else decides what to do with this.
3) Build a Gui on top of this, view seperated from logic. Is a programming
technique thought around the world today ;)
This is from a programmers perspective, and IMO the way it should be looked
at while designing.
> This propably requires little bit of explaining.
>
> 1) UI: This should be pretty clear: the app should not be limited to KDE
> only as it would?be more than handy to access, say, project status page
> through the Web.
right, see comment below.
> 2) APP: The reason for separating app functions is that this way we get
> more flexible connectivity to both db and UI direction.
> At the app level there are objects (task, resource, res.alloc) that
> perform tasks (create, delete, allocate something).
> As these objects has functions, thay can be accessed from UI (remote or
> local) and they can access data in any db (local dBase-III file or
> remote SQL server).
Use DCOP for this, your app would be running without a front-end and another
app would be the web-interface. They communicate via DCOP.
You could make the main app do the same with its main GUI, but that is not
as fast as you would like, so just building on top of this seems the best
way to go.
> 3) DB: This is separated from APP because this may be located in
> completely different machine. It talks to APP using data objects that are
> really data entities. DB side turns them into SQL or dBase codes and
> commands and what is returned back to APP is just another data object
> gathered from all sorts of data tables.
In practice the data objects will present a stream of data (in xml probably)
which can then be saved into anything, use the KDE <-> Database coupling
for this, don't implement what others have made ;)
But before we overschedule ourselves, lets forget the things that can always
be done, and create a nice data-model. With keeping in mind that extentions
are going to happen, impacting the design to make it extensible.
--
Thomas Zander zander@earthling.net
The only thing worse than failure is the fear of trying something new