posts - 84,  comments - 880,  trackbacks - 7


1. Provide external interface for searching. Based on this functionality multiple

InterDOW systems can be joined to provide world wide content searching.

2. Organize a web site as the same as a directory tree in an operating system. All the

web pages and subsites are managed as a node of the tree.

3. In order to support multiple languages more easily, organize and store all the used

titles and captions and other strings that would appear on the UI in a resource table,

mostly like what have been done in VC.

4. In the InterDOW system, some condition judgements or rules should be able to be

applied to each actions or operations, such as inserting, updating, and deleting an



5. Use the unique OID for object comparison by default.

6. Each article should and must be under any one of the three state during its life time

in InterDOW system. They are state under editing, approved state for publishing, and

finally in the trash after deleting. And once an article is published to the web site,

it must be bound to at one node in the site map tree.


7. Add User as a system class, and Permission as a system relation, so that authorities

and privileges can be handled at the system level.

8. In addition, extend class and relation as system class. As a result of this, all the

class and relation definitions can be accessed and treated as normal objects, and this

indeed enhanced the system greatly! A system class means a class which is preserved and

protected by the system. As a user maybe you have only read permission on it.

9. Add a new base data type as Pointer, which is composed of an ObjectID and a ClassID.

10. An InterDOW site should be able to be configured as a subsite of another one.

11. Attributes should be ordinal.


12. Add an extra index table that stores shortcut entries to all the objects. Using this

indexed table, you can access a specific object directly and quickly by providing the

object's OID.

13. Finite State Machine is god-given methodology in resolving complex logical processes

or protocols.

14. Enhance the functionalities of doing statistics. Need annual, monthly, weekly, and

daily statistics on the whole site and each page, each article and even each object, and

also the statistics on each IP address.

15. An InterDOW system should be able to communicate with the other data source. At

least, data communications between two InterDOW systems are necessary and unlackable.


16. Treat relation as a system class. And relations are specialized object that can

automatically join all related role objects together for query.

17. Each article can have an index string, and we could gather these index strings

together into one table with each index string having direct pointer to the coresponding

article, so that users can search articles very quickly and conveniently by index, and

also the returned search results would be more meaningful and make more senses.

18. Classes and Templates can only be reused in the same InterDOW system, but can also

be exported outside for backup, and the exported classes and templates can be imported

and reused by other systems.


19. We can change the font size of the current page dynamically by using JScript.

20. The InterDOW system should have the functionality of displaying information of

online visitors.

21. WODMark can be executed recursively. That is the result of one mark can still

contain marks, and also need futhure recursive replacement. This feature is convenient

for an atomic string field to contain dynamic informations.


22. A purely script-coded version of InterDOW is necessary, as it does not need the

additional DLL support and can run smoothly in most virtual hosts of web-space

providers. The light-weight edition, however, is a functionality restricted edition for

it can only read the contents and execute the functions that have already been developed

by others. I call this restricted edition as 'InterDOW Reader', while the fully

functional edition as 'InterDOW Developer' or just 'InterDOW'.


23. Append a ReferenceCounter field, right after the UID field, to each data resource


24. It's necessary to extend SQL and implement OQL, that is the short of Object Query

Language. Use the 'Subclass OF Class' or 'Mapping OF Class' syntax in OQL to represent

an exact base table in SQL.

25. In OQL, the 'OF' syntax can be used in SELECT and UPDATE statements, and is illegal

in INSERT and DELETE statements.


26. The two folders, named 'Files' and 'Assemblies', are necessary to store files

outside the database and assemblies that would be loaded dynamically at runtime.

27. Task and Message Notifications must be provided as a built-in functionality. Thus,

all tasks and messages including those of their derived type can be toally retrieved to

their respective owner.

28. Develop a trivial readonly edition of InterDOW for ASP environment.


29. Use the ProfileCenter to provide the service of SSO(Single Sign-On). All the

InterDOW sites that are registered on the same profile center can share their profile

data among each other.

30. Each state node has a counter to statistic how many times it has been continuously

recycled on.

31. Provide the functionality of statistic the percentages each approval result.

32. Each persistent object including Page should have a Viewer and an Editor. Template

and Library should have a counterpart for each Skin. There is a set of styles, each skin

should all themes, and choose one theme to apply at one time. And, also, Controls,

Viewers and Editors are Skin and Theme awareness.


33. Process can define parameters for the purpose of communicating with the callers

outside. And parameters can have in/out modifiers. This feature is very useful when a

sub process is being called.

34. Each Viewer/Editor must be bound to a specific persistent Type. And, a persistent

type can have multiple viewers and editors. Objects of extended types can be processed

by the base type's Viewers and Editors.

35. InterDOW will use two databases to respectively store the content to be published on

the web and the draft that is currently being edited. Meanwhile, it will also provide

the functionality of synchronizing these two databases.


36. InterDOW should allow some pages or some web elements to be shown using other skins

or themes that are different to the currently selected skin or theme.

37. Viewers and Editors should be able to be parameterized, and able to indicate the

visibility & editability of sub fields.

38. Some rights settings conform to specific environments or contexts, there is no need

to load all the rights settings every time InterDOW makes a security judgement.

39. You can define resource closures in InterDOW, and then assign a user the rights to

do administrative operations on that closure.

40. InterDOW should support the union of sub systems outside.

41. InterDOW need a HelpSystem.


42. Online Documents; Distributed Computing; Globalized Site.

43. M.V.C Model, the three aspects/factors should be separated completely and entirely.

44. Supports various presentation forms, e.g. HTML, XML, WML, WinForm, XAML, Flash,

plain text or even binary stream, etc.

45. The Flow Control, Security, and Reporting System is very important and necessary!


46. Viewers & Editors for persistent objects will have verbs, for instance, Hide() and

Lock(). A Viwer can Hide, and an Editor can Hide and Lock. These verbs can be invoked at

run time, and furture more, they can be used to set the access modifier on Viewers &

Editors, thus they can be hidden or locked. This feature allows some furture

customization and adjustment. These access modifiers are not stored in Viewers & Editors

themselves, actually they are specified when Viewer & Editor instances are dropped onto

the designer surface, that is they are stored in the pages or other Viewers/Editors that

contain or involve them.


47. Use Dynamic Compilation technology in Pages, Viewers and Editors for ouput the

presentation interfaces programmatically.

48. Various kinds of tags are available in InterDOW: Data Tag, Control Tag, and

Logical/Flow Tag.

49. A Directory can have some groups and a group can be bound to a list, and a list can

be static or dynamic.

50. Virtual Driectory can link to another directory, but directory linking can not be

passed on, that is referred directory will be omitted when a virtual directory is

expanded. And, virtual directory can still have child directories, and they would

override or hide the referred sub directory with the same name.


51. Design the run time Document Object Model for InterDOW pages and other presentation

elements. By this DOM, users can access any elements in the document hierarchy tree,

modify them, and even add new elements, delete existing ones, and all the operations

will immediately be updated to the presentaion surface. Quite a flexible programming

model it will be!

52. An Editor has a collection of client submitted values. Before the submitted input

values are updated to the bound object you can do some verifications/validations on

them, or do some other operations on them. By the way, if you want, you can also ask

either Viewers or Editors to store the values displayed in the previous response.


53. MVC = DataEngine(Swallow) + RepresentationEngine + FlowControlEngine. Other systems

are SecuritySystem, OrganizationSystem, SitePublicationSystem.

posted on 2005-03-13 19:17 Laser.NET 阅读(...) 评论(...) 编辑 收藏