philmaker: Initial Helma Purpose, Project

Version 11 by philmaker on 21. November 2007, 22:52

4	Related: implement JSON store for Helma?

Version 10 by philmaker on 21. November 2007, 22:49

2
3	See also: http://couchdb.org/

Version 9 by philmaker on 21. November 2007, 22:47

philmaker's initial goal for using Helma is to create a lazy data store for AJAX requests. If the client app posts data via a URL which Helma is not prepared for, I want Helma to accept the AJAX post and store the posted data under the user HopObject at that path in the internal database. This would be like: superCRUD during client-focused development and application prototyping. Analogy: on my desktop computer, when I save a file which does not exist, my operating system offers to save the file for me and asks for a location. I want to do the same thing for AJAX requests - even if some dialog may need to pop up in the client app. Helma does seem well equipted for this because it has a built in hierarchical database and because Helma apps are also implemented in Javascript, the same language as many of the client side Javascript AJAX frameworks. Servlets have the concept of filters but Helma may not. So I may need to intercept the request and handle it somehow in Helma - to prevent 404 not found - possibly even if that means that I need to chain HopObjects to match the url request on the fly. Not sure how to do this yet: Chris mentioned getElementAt() maybeyet.

Version 8 by philmaker on 21. November 2007, 07:08

philmaker's initial goal for using Helma is to create a lazy data store for AJAX requests. If the client app posts data via a URL which Helma is not prepared for, I want Helma to accept the AJAX post and store the posted data under the user HopObject at that path in the internal database. This would be like: superCRUD during client-focused developmentdevelopment and application prototyping. Analogy: on my desktop computer, when I save a file which does not exist, my operating system offers to save the file for me and asks for a location. I want to do the same thing for AJAX requests - even if some dialog may need to pop up in the client app. Helma does seem well equipted for this because it has a built in hierarchical database and because Helma apps are also implemented in Javascript, the same language as many of the client side Javascript AJAX frameworks. Servlets have the concept of filters but Helma may not. So I may need to intercept the request and handle it somehow in Helma - to prevent 404 not found - possibly even if that means that I need to chain HopObjects to match the url request on the fly. Not sure how to do this yet: Vhris Chris mentioned getElementAt() maybe.

Version 7 by philmaker on 21. November 2007, 07:05

philmaker's initial goal for using Helma is to create a lazy data store for AJAX requests. If the client app posts data via a URL which Helma is not prepared for, I want Helma to accept the AJAX post and store the posted data under the user HopObject at that path in the internal database. This would be like: superCRUD during client-focused development. Analogy: on my desktop computer, when I save a file which does not exist, my operating system offers to save the file for me and asks for a location. I want to do the same thing for AJAX requests - even if some dialog may need to pop up in the client app. Helma does seem well equipted for this because it has a built in hierarchical database and because Helma apps are also implemented in Javascript, the same language as many of the client side Javascript AJAX frameworks. Servlets have the concept of filters but Helma may not. So I may need to intercept the request and handle it somehow in Helma - to prevent 404 not foundfound - possibly even if that means that I need to chain HopObjects to match the url request on the fly. Not sure how to do this yet: Vhris mentioned getElementAt() maybe.

Version 6 by philmaker on 21. November 2007, 07:04

philmaker's initial goal for using Helma is to create a lazy data store for AJAX requests. If the client app posts data via a URL which Helma is not prepared for, I want Helma to accept the AJAX post and store the posted data under the user HopObject at that path in the internal database. This would be like: superCRUD during client-focused development. Analogy: on my desktop computer, when I save a file which does not exist, my operating system offers to save the file for me and asks for a location. I want to do the same thing for AJAX requests - even if some dialog may need to pop up in the client app. Helma does seem well equipted for this because it has a built in hierarchical database and because Helma apps are also implemented in Javascript, the same language as many of the client side Javascript AJAX frameworks. Servlets have the concept of filters but Helma may not. So I may need to intercept the request and handle it somehow in Helma - to prevent 404 not found.

Version 5 by philmaker on 21. November 2007, 07:04

philmaker's initial goal for using Helma is to create a lazy data store for AJAX requests. If the client app posts data via a URL which Helma is not prepared for, I want Helma to accept the AJAX post and store the posted data under the user HopObject at that path in the internal database. This would be like: superCRUD during client-focused development. Analogy: on my desktop computer, when I save a file which does not exist, my operating system offers to save the file for me and asks for a location. I want to do the same thing for AJAX requests - even if some dialog need to pop up in the client app. Helma does seem well equipted for this because it has a built in hierarchical database and because Helma apps are also implemented in Javascript, the same language as many of the client side Javascript AJAX frameworks. Servlets have the concept of filters but Helma may not. So I may need to intercept the request and handle it somehow in Helma - to prevent 404 not found.

Version 4 by philmaker on 21. November 2007, 07:02

philmaker's initial goal for using Helma is to create a lazy data store for AJAX requests. If the client app posts data via a URL which Helma is not prepared for, I want Helma to accept the AJAX post and store the posted data at that path in the internal database. This would be like: superCRUD during client-focused development. Analogy: on my desktop computer, when I save a file which does not exist, my operating system offers to save the file for me and asks for a location. I want to do the same thing for AJAX requests - even if some dialog need to pop up in the client app. Helma does seem well equipted for this because it has a built in hierarchical database and because Helma apps are also implemented in Javascript, the same language as many of the client side Javascript AJAX frameworks. Servlets have the concept of filters but Helma maybe may not. So I may need to intercept the request and handle it somehow in Helma - to prevent 404 not found.

Version 3 by philmaker on 21. November 2007, 07:01

philmaker's initial goal for using Helma is to create a lazy data store for AJAX requests. If the client app posts data via a URL which Helma is not prepared for, I want Helma to accept the AJAX post and store the posted data at that path in the internal database. This would be like: superCRUD during client-focused development. Analogy: on my desktop computer, when I save a file which does not exist, my operating system offers to save the file for me and asks for a location. I want to do the same thing for AJAX requestsrequests - even if some dialog need to pop up in the client app. Helma does seem well equipted for this because it has a built in hierarchical database and because Helma apps are also implemented in Javascript, the same language as many of the client side Javascript AJAX frameworks. Servlets have the concept of filters but Helma maybe not. So I may need to intercept the request and handle it somehow in Helma - to prevent 404 not found.

Version 2 by philmaker on 21. November 2007, 07:01

philmaker's initial goal for using Helma is to create a lazy data store for AJAX requests. If the client app posts data via a URL which Helma is not prepared for, I want Helma to accept the AJAX post and store the posted data at that path in the internal database. This would be like: superCRUD during client-focused development. Analogy: on my desktop computer, when I save a file which does not exist, my operating system offers to save the file for me and asks for a location. I want to do the same thing for AJAX requests. Helma does seem well equipted for this because it has a built in hierarchical database and because Helma appas apps are also implemented in Javascript, the same language as many of the client side Javascript AJAX frameworks. Servlets have the concept of filters but Helma maybe not. So I may need to intercept the request and handle it somehow in Helma - to prevent 404 not found.

Version 1 by philmaker on 21. November 2007, 06:58

philmaker's initial goal for using Helma is to create a lazy data store for AJAX requests. If the client app posts data via a URL which Helma is not prepared for, I want Helma to accept the AJAX post and store the posted data at that path in the internal database. Analogy: on my desktop computer, when I save a file which does not exist, my operating system offers to save the file for me and asks for a location. I want to do the same thing for AJAX requests. Helma does seem well equipted for this because it has a built in hierarchical database and because Helma appas are also implemented in Javascript, the same language as many of the client side Javascript AJAX frameworks.