[Helma-user] questions and ideas

[kRAkEn/gORe]

hi daniel,
thanx for the response, do you have any hint on how to do that ?

On 5/25/07, Daniel Ruthardt <daniel.ruthardt at dowee.com> wrote:
>
>  Hi,
>
>  couldn't you just use another repository implementation which is capable of
> parsing things the way you want it to be parsed?
>
>  Greetings,
>  Daniel
>
>  kRAkEn/gORe wrote:
> 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 :)