[Dynapyide-developer] ATTENTION: Spec Proposal

[<hv...@ya...>]

OK, I skimmed through various JavaBeans - and other - resources to try
and figure out wheter it is an technique to consider further. As stated,
EJB is overkill for our application which first and foremost is a
clientside desktop application. (It could though be expected that in the
future someone would want to implement it fully or partly server-side -
which I think the architecture I have in mind would be able to support
or adapt to.)

Anyways, here follows what I'm currently planning to outline in more
detail in a specification docs. Please let me know if you have any
further thoughts, ideas or comments (corrections?) that I can use in the
specs.


********************************************
DynAPI <!-- IDE --> Specification [Proposal]
********************************************

Just for everyone to get a glance and a chance to have a say before i
let loose on the more detailed specifications.

Features
=3D=3D=3D=3D=3D=3D=3D=3D

Well, there certainly would be a lot features you could wish for, but to
keep it relizable you have to limit down to what is the essence of what
your application should be able to do. That's why the number of core
features are kept down to a minimal useful application, and then some
additional features that could be added, even though not necessary. The
latter serve as a mind keeper as to keep the implementation as open to
extensability and reuse as possible. (Now don't be shy! I know you must
have thousand of ideas and desires as to what the final application
should be like - see this as your chance to get the features you wish
for or at least get your ideas evaluted by other minds (and maybe
someone gets an great additional idea :) ).

Core features:
--------------

- Open, create & save clientside HTML documents with clientside
ECMA/Javascript

- Edit HTML with at least ECMA/Javascript & DOM 2 support in WYSIWYG
(graphical) & Code modes

- Widget/Object generation & edit

- Application component extensability

- Application scripting ECMA/Javascript-support (Rhino)

- Help/documentation integratation

- Logging, output and save (at least during initial development)

(any core features missing?)


Additional (future) features:
-----------------------------

- Drag & Drop support

- Configuration GUI

- L&F switching

- Project managment

- JSDoc (Javascript JavaDoc-like implementation)

- Online extension check & download at runtime

- Resource respositary (code snippets etc)

- Codeview tools integration (maybe adapters for Jedit, Jext or other
text/code-only tool's extensions)

- Online references and validation integration

(any additional ideas?)


Design
=3D=3D=3D=3D=3D=3D=3D=3D

Design pattern
--------------

The architecture is of a similar type to the MVC architecture. It is a
3-tiered that conforms very well with most modern standard
design-thinking.=20

First tier:

Usually named Presentation Layer in most models and frameworks. It
consists of MODULES - visual components that builds up the Application
GUI by providing graphical presentation of the contemporary working
data. (These are the ones most conforming to the traditional JavaBean).=20

Second tier:

In most models is called Buisness Layer or Buisness Logic. Here we have
two type of component types: MANAGERS who basically manages collections
of a certain type of data objects and HANDLERS that handles one data
object a time.

Third tier:

Commonly known as the Data Layer. Data in this pattern is catogerized as
this:

* Configuration Data

* Application Scripts

* Documents

* Scripts

* Tempelates

(can you think of any missing type of data? think of it as an stand
alone object different than those mentioned, and if you can: let me know
of it )

Method & Models
---------------

For the method, the choice is Component Based Design (CBD). The choice
is based on both current trends in application development in general
and WEB application development in specific ( because, though this is
not essentially a webapplication, most of its users will more than
probably be acustommed to the componentbased thinking - at least sooner
or later ).

There is also practical and desired gainings of using a CBD model.
Flexability of maintaing and extending the application over time is
highly valued, as well as being able to just wrap and use existing Open
Source products - which will reduce development in both time and efforts
to implement features correctly.

Techniques & Tools
------------------

As the foundation for the application we will use the JavaBeans
technique as implemented in the Sun JDK 1.4 SE. The 1.4 version
specifications adds new desired features to the JavaBeans API which has
higher priority over backwards compability with an intended audiance of
developer "tech-heads" living on the edge of the technical frontier.

For our default Graphical User Interface (GUI) in the Presentation Layer
we use SWING. Since the requirements on the JavaBeans is set to the JDK
1.4 SE we don't need to apply any backward compability any lower than
that (which essentially means no backwad compability currently, since
that is the latest JDK-version released at this time).

Services
--------

Not necessarily implemented the .NET or EJB webservices-way, the
following are what I figure the system of the application must perform
in order to function as per the outlined core. (The concept thinking is
that all supported languages and APIs is some way conforms and are
translated/parsed to and from a generic DOM - Document Object Model -
based on the W3C HTML/XML DOM)

* DOM Parsing: HTML & ECMA/Javascript to generic DOM object/s and
possibility to add DynAPI, CSS and other W3C DOM-compatible techniques
(Apache Jakarta ECS candidate for markup languages and Rhino for
ECMA/Javascript - encapsuled in parser component wrappers)

* DOM Rendering: from generic DOM object/s to WYSIWYG - and possibly
preview - graphical view

* Buffering: temporary memory-buffering of open documents - in generic
DOM object/s - at runtime (additional subfeature: runtime autosave to
temp XML-file of the generic DOM in open documents - like the MS Word
feature - for session recovery)

* File: Reading from & writing to file/s (additional subfeature:
multiple files written by setting of one DOM object)

* DOM Syncing: to sync unparsed files against a generic DOM (could be
used both to see if a file is unsaved or if an application start is
following an fatal application termination)

* Logging: getting info on the application run

* Component: managment and handling of the applications components

The DOM services should probably have a parent services that is more
general in interface than DOM-specific, even if that's the only current
applicable use we have. I'm biased about making it DOM Service that then
subs into the diffent contexts or the contexts that subs into DOM
specfic components - also am unsure which is more in line with the CBD
philosophy - if any.

The JavaBeans BDK probably does the component managment and handling in
major parts, probably leaving the (below mentioned) Component Service
mostly covered. I however think we better wrap it into own components,
so we can add additional features and such if we would feel the urge to.
However, we should not complicate things too much, so initially we don't
need to give this so high priority, but also - if implemented - we
shouldn't wait to long either or it might turn out a chore task.

(this is the most crucial part, which comes done to the understanding of
CDB's core - I really feel I need some feedback on this)

***

That's as far as my brain can extend to today. I'd like to have an
online chat with as many as possibly on Spec & Design for topic.=20
Could everyone that have hanged on this far reading the message report
to me what possible Instant Messaging & Conferance services they are
able to use and some possible dates and time (please convert it to GMT
standard thank you)

And as stated you are more than welecome to suggest editions, additions
or just some feedback on the above outllined specs. Anything is
apprieated! Even flames if you feel like it! Response and feedback is
what Open Source projects live on according to some article I read on
the Apache Jakarta website - lack of it causes projects to die.

Hope you are reading this or my efforts will be in vain - and I'd hate
that

Henrik V=E5glin, your devoted project manager still at it - though being
slow and lazy ;)