[Helma-user] questions and ideas

[kRAkEn/gORe]

hi to all,
i would like to know if is possible to divide Hop concept from real
server processing in helma, and what i need to keep out from the core
library if i want to achieve this.
i mean, i like very much the idea of have a powerful container with
java classes directly scriptable in javascript and lots of objects
mapped directly in the scripting engine, but i do not feel comfortable
with object publishing, cause i work with big complex geo-spatial
databases, and sometimes it isn't so simple to prototypize records
cause they are result of geographical operations such as intersections
and unions and so on.
also, i feel that the actual directory structure of an application is
somehow limiting, cause i can't have the directory structure i want,
but instead i have to use a fixed naming convention. actually to avoid
this, i've changed the name of my files into the directories, so they
aren't parsed by helma and interpreted as objects, and i use them in a
more elastic (ruby style) model-view-controller structure.
so for helma2 i see these points, split helma in 3 parts with plugins support:
server - executor - support

  * helma2 (server): is only the servlet publisher with rhino
scripting engine, with request/response
    mapping, session support and possibility to attach handler plugins
  * hop (executor): a handler plugin that will understand a set of
directories, naming conventions,
    that will search for objects and map prototypes to real javascript code
  * hof (support): helma object framework, javascript help/utils
classes that lives independently

this way you can select to replace the executor "hop plugin", with a
executor "mvc plugin" that will look into applications directory, but
don't parse type.properties, instead it will look for folders as
modules, and in there search for a action/controller/skin file that
lives in a independent manner. so this way you separate the scripting
engine servlet from the real executor, keep separate the low level
stuff (requests, threads, sessions...) from mid level stuff (scan code
for changes, publishing objects, and so on...). obviously high level
will be the real application (which can make use of includes object
from the javascript helma framework).
imho this will not block everyone to work with helma, if they can't
work directly with object mapping (but keeping things simpler and
cleaner).

just my 2cents. let me know what u think about this

ah, i've added support for onSessionBegin / onSessionEnd, not cleanly
written (should be part of the application and not the SessionManager
but it works). that was another thing i lackfrom helma :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SessionManager.java
Type: text/x-java
Size: 8656 bytes
Desc: not available
Url : http://helma.org/pipermail/helma-user/attachments/20070525/1d9f6f0c/attachment-0001.bin