[Helma-user] questions and ideas

[kRAkEn/gORe]

mmmh even if i don't think writing a repository is the right thing. i
need to change action files, have them with another file extension,
and have the possibility to place them in different directories from
Root, and still have them accessible from a url path, without hassle
with type.properties, skins and such... is a new repository enough for
this ?

On 5/25/07, kRAkEn/gORe <kunitoki at gmail.com> wrote:
> 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 :)
>