|
From: <hv...@ya...> - 2002-05-06 21:31:45
|
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 ;) |