[Dynapi-Help] DynAPI RAD proposal [ was Re: DynBuilder proposal ]

[Henrik V�glin]

OK, so I have reworked my proposal. I also renamed it since I figured DynAPI RAD is more appropoirate on a fully-fledge application opposed to a simple DynAPI-integrated webapplication IDE. Please let me know what you think...   ===   DynAPI RAD [Rapid Application Development] tool ===================================== draft proposal 2000.12.31 [DynBuilder]     revised 2001.01.06  by Henrik V�glin [[EMAIL PROTECTED]] ******************************************   // INTRODUCTION   DynAPI RAD is to be an IDE (Intregrated Development Enviroment)aimed at fasten the development of DynAPI 2 featured webpages & webapplications. It does mostly build on drag&drop and an easy to use GUI (graphical user interface), but it does not however replace the need for understanding DynAPI or DHTML basics. It does though give a good experimental base as it makes it easy to overlook how DynAPI DHTML features are integrated into different browsers through ease of use and preview directly in webbrowsers installed on the local system - which enables the developer to at all make sure that it works as inteded across browsers.   // DEFINITIONS   For this structure proposal I'm considering all documents, dynlayers, widgets etc - ie any part of the page under editing - as objects (Object Oriented as it should be, no?). To define a distinction between objects of the page and those of the builder, I'll call the latter for modules. Modules are essentially tools used for editing or viewing objects in the workspace (ie the page in editing). It could also be other things - only the vision of the mind is the limit here.   Some of the modules are called managers. Managers doesn't directly control objects, but instead either extends the user interface by handeling objects or other modules for navigation or working with some vital task in the background.   // MODULES   ****************************************************************  [*] = to be implemented  [?] = to be considered for the future  [#] = under development  [+] = added  [-] = removed  [!] = cannot currently be done or implemented (even though needed) ****************************************************************   / Managerlevel (ie not visible):    [*] Pagemanager: Handles loading and saving a page (or several pages maybe), createing an instance of the page with proper HTML, JS and DynAPI default code    [*] Objectmanager: Handles loading new instances of objects into the document under edit and placing them according to the users placewment and correct in the code.    [*] Focusmanager: Enables the RAD to know which object (even the page itself) is currently in focus and sends it to the focusviewer.    [*] Propertymanager: Reads out the avaialble properties of an object and writes out to the propertyviewer. Handles property modifications & changes done to any object; edits & adds to the code as necessary to represent these.    [*] Classmanager: Handles reading out classes from the DynAPI library and loading into classviewer.    [*] Binmanager: Keeps objects (with its set properties) after removal from the pageobject code, for easy restoring. emptied first on command. Saves to a non-page text document for retrival after the page is closed down    [?] Dockingmanager: Handles docking/floating ability of visible modules.    [?] Keymanager: Handles assigning of keys (and mouse commands) to different functionalities of the application.(I'm a semi-gamer, so that's why this is desirable).    [?] Languagemanager: Handles loading and changing a custom language files that translates in-appliction (maybe also save to language file - see below on language setter description)   / Viewlevel:    [*] Propertyviewer: Recieve the avaialble properties of the currently focused object and its values from propertymanager as the object loads.    [*] Codeeditor: Gives the user direct view and access to edit code.    [*] WYSIWYGeditor: Gives the user direct view and access to edit in semi-final visual mode.    [*] Classviewer: Present the currently selected (and therefor loaded) class, its name and developer info (name/alias,[email address,[homepage URL]])    [*] Focusviewer: Present the currently focused object    [*] Bin viewer: Compact view of recently deleted objects. presents a way for the user to let it send command to binmanager to empty all or partially (file-by-file).    [?] Keyassigner: Let's the user set custom key or key-combos to application functionalieties    [?] Languagesetter: Set language-translation for the GUI (and customisation - ie set own words to assign to the functions)   // MODEL   There's no doubt a OO (Object Oriented) approach is the way to go and as such modules are treated as objects (not to be confused with the generated objects though). In this case modules are childs of its parent level.   As seen above there are 2 levels of the UI, but actually there are 4 levels total of which the application itself is the topmost one and the second is the browser/s - which we can't change but take advantage of. Reference is always done to the top (as to allow - but not force - the application to save outcome of an action) parallell with referencing to the appropirate module. Most of the managerlevel managers will of course serve the viewlevel editors and viewers and be reading the browser or application, but they will also be in reference and serve eachother and in this case they are equal. equal means they don't have any kind of priority over each other - but in case of a conflict one of them should "realise" it is dependant on the other and step back (I'm not sure when this would ever occur, but the model supports it in any case).   Something like this:   Application *********** | | | +--[configuration & DynAPI files] | | | Browser | *********** | | | | | +--[this must be specified according to the browsers] | | | | | Managers | | *********** | | | | | | | +--[managerlevel modules] | | | | | | | Vievers/editors | | | *************** | | | | +-------+-------+-------+--[vievlevel modules]   The application is merely like an rootmemory for everything under it. It would be able to add parallel levels to this, but I see no point it that right now.   // PROJECT ASSIGNMENTS   As to divide this monsterous task, I propose that developers take on one (or more if able) and try to finish it predocument as much as possible of the induvidual modules properties, input and output and then continue to document during development. Seeing how this have turned out earlier I should really present a model and some methods for this too, but since this is an unestablished proposal it can't be done at this stage more than to follow the modules outline above.   I could accept the assignment of either project manager (including compiling documentation) or GUI/graphics designer, but only if I'm accepted as such - let me know what you all think...   [ BTW: If whoever registered "ObjectMarkupInterface - DynAPI" as new project at Sourceforge is on the list - please let me know if I can be a part... ]   // COMMENTS   If anybody have comments, suggestions or additions to this proposal, please do post'em to the list or notify me. All input are welecome - even if you are a strong opponent to this proposal let know - so it can be better aligned with everyones expectations. If you like it and want to become a part of DynAPI RAD team and contribute to its development, mind you all doors are open to do so since this no less open source than the rest of DynAPI (or sourceforge) - and since my main focus with the model is to make the DynAPI RAD as open for extensability as DynAPI itself, there will always be something to work on.   Henrik V�glin [[EMAIL PROTECTED]]