[Helma-user] questions and ideas

[Daniel Ruthardt]

Although Helma still would want to be feed with .hac files, 
type.properties and so on in the end, a new repository implementation 
could in general solve your problems.
It would have to map your file organization scheme, file extensions and 
the way how you want your objects being accessible from url path to what 
Helma actually expects.
For the latest, your repository implementation probably would need to 
create in-memory virtual type.properties on the fly.

Have look at
http://grazia.helma.at/pipermail/helma-dev/2007-May/003571.html
to see how such an extended repository implementation could look like.

Greetings,
Daniel


kRAkEn/gORe wrote:
> 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 :)
>>>       
> _______________________________________________
> Helma-user mailing list
> Helma-user at helma.org
> http://helma.org/mailman/listinfo/helma-user
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://helma.org/pipermail/helma-user/attachments/20070525/e4ca2848/attachment.html