helma.org/wiki/Workspace/philmaker/philmaker: Initial Helma Purpose, Project

Version 11

philmaker — Wed, 21 Nov 2007 22:52:29 +0000

4	Related: implement JSON store for Helma?

Version 10

philmaker — Wed, 21 Nov 2007 22:49:32 +0000

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

Version 9

philmaker — Wed, 21 Nov 2007 22:47:18 +0000

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

philmaker — Wed, 21 Nov 2007 07:08:02 +0000

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

philmaker — Wed, 21 Nov 2007 07:05:50 +0000

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

philmaker — Wed, 21 Nov 2007 07:04:33 +0000

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

philmaker — Wed, 21 Nov 2007 07:04:10 +0000

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

philmaker — Wed, 21 Nov 2007 07:02:20 +0000

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

philmaker — Wed, 21 Nov 2007 07:01:55 +0000

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

philmaker — Wed, 21 Nov 2007 07:01:11 +0000

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

philmaker — Wed, 21 Nov 2007 06:58:57 +0000

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.