CMS twoday vs antville vs gobi
2007-05-02 04:26:44 GMT
_______________________________________________ Helma-user mailing list Helma-user <at> helma.org http://helma.org/mailman/listinfo/helma-user
_______________________________________________ Helma-user mailing list Helma-user <at> helma.org http://helma.org/mailman/listinfo/helma-user
Hi all, I have a 'post' prototype with a date field (linked to a mysql table) - I want to be able to divide the posts up into an archive like: year -> month -> day -> post I thought about grouping the posts by year, then by month (children of by year) and then by day (children of by month) - but I'm unable to use the groupname of a grouped collection in a filter statement -> I can't see the months in 2007 for example. Does anyone have any advice how best to do this? Should I make an extra table or something? It feels like it should be so easy - I must be missing something! grts- Jonathan
hello
i am stumbling across a strange error message when i try to invoke the following line (and only this line)
with a current helma snapshot as of today and rome 0.9 [1]:
var output = new Packages.com.sun.syndication.io.SyndFeedOutput();
in the browser i only get:
org/jdom/Document
and in the stack trace:
[2007/05/02 15:32:05] [ERROR] test2:get:test2/debug: org/jdom/Document
java.lang.NoClassDefFoundError: org/jdom/Document
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
at java.lang.Class.privateGetPublicMethods(Unknown Source)
at java.lang.Class.getMethods(Unknown Source)
at org.mozilla.javascript.JavaMembers.discoverAccessibleMethods(JavaMembers.java:348)
at org.mozilla.javascript.JavaMembers.discoverAccessibleMethods(JavaMembers.java:324)
at org.mozilla.javascript.JavaMembers.reflect(JavaMembers.java:418)
at org.mozilla.javascript.JavaMembers.<init>(JavaMembers.java:67)
at org.mozilla.javascript.JavaMembers.lookupClass(JavaMembers.java:749)
at org.mozilla.javascript.NativeJavaClass.initMembers(NativeJavaClass.java:79)
at org.mozilla.javascript.NativeJavaClass.<init>(NativeJavaClass.java:74)
at org.mozilla.javascript.NativeJavaPackage.getPkgProperty(NativeJavaPackage.java:159)
at org.mozilla.javascript.NativeJavaPackage.get(NativeJavaPackage.java:105)
at org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:1546)
at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1374)
at org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1363)
at org.mozilla.javascript.gen.c433._c4(C:\Work\helma\..\apps\test2\code\Test\Test.js:51)
at org.mozilla.javascript.gen.c433.call(C:\Work\helma\..\apps\test2\code\Test\Test.js)
at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:386)
at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2823)
at org.mozilla.javascript.gen.c433.call(C:\Work\helma\..\apps\test2\code\Test\Test.js)
at org.mozilla.javascript.Context.call(Context.java:520)
at helma.scripting.rhino.RhinoEngine.invoke(RhinoEngine.java:296)
at helma.framework.core.RequestEvaluator.run(RequestEvaluator.java:389)
at java.lang.Thread.run(Unknown Source)
[2007/05/02 15:32:05] [INFO] test2:get:error aborted after 0 millis
does anyone know what's going on here?
ciao,
tobi
--
[1] https://rome.dev.java.net/
uh, of course: jdom.jar is missing... my mistake. (should have waited one more minute before sending the message.) :) ciao, tobi tobias.schaefer <at> orf.at wrote: > hello > > i am stumbling across a strange error message when i try to invoke > the following line (and only this line) with a current helma snapshot > as of today and rome 0.9 [1]: > > var output = new Packages.com.sun.syndication.io.SyndFeedOutput(); > > in the browser i only get: > > org/jdom/Document > > and in the stack trace: > > [2007/05/02 15:32:05] [ERROR] test2:get:test2/debug: org/jdom/Document > java.lang.NoClassDefFoundError: org/jdom/Document > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Unknown Source) > at java.lang.Class.privateGetPublicMethods(Unknown Source) > at java.lang.Class.getMethods(Unknown Source) > at > > > > > > > > > > > > > > > > > > > > > org.mozilla.javascript.JavaMembers.discoverAccessibleMethods(JavaMembers.java:348) > at > org.mozilla.javascript.JavaMembers.discoverAccessibleMethods(JavaMembers.java:324) > at org.mozilla.javascript.JavaMembers.reflect(JavaMembers.java:418) > at org.mozilla.javascript.JavaMembers.<init>(JavaMembers.java:67) at > org.mozilla.javascript.JavaMembers.lookupClass(JavaMembers.java:749) > at > org.mozilla.javascript.NativeJavaClass.initMembers(NativeJavaClass.java:79) > at > org.mozilla.javascript.NativeJavaClass.<init>(NativeJavaClass.java:74) > at > org.mozilla.javascript.NativeJavaPackage.getPkgProperty(NativeJavaPackage.java:159) > at > org.mozilla.javascript.NativeJavaPackage.get(NativeJavaPackage.java:105) > at > org.mozilla.javascript.ScriptableObject.getProperty(ScriptableObject.java:1546) > at > org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1374) > at > org.mozilla.javascript.ScriptRuntime.getObjectProp(ScriptRuntime.java:1363) > at > org.mozilla.javascript.gen.c433._c4(C:\Work\helma\..\apps\test2\code\Test\Test.js:51) > at > org.mozilla.javascript.gen.c433.call(C:\Work\helma\..\apps\test2\code\Test\Test.js) > at > org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:386) > at > org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2823) > at > org.mozilla.javascript.gen.c433.call(C:\Work\helma\..\apps\test2\code\Test\Test.js) > at org.mozilla.javascript.Context.call(Context.java:520) at > helma.scripting.rhino.RhinoEngine.invoke(RhinoEngine.java:296) at > helma.framework.core.RequestEvaluator.run(RequestEvaluator.java:389) > at java.lang.Thread.run(Unknown Source) [2007/05/02 15:32:05] [INFO] > test2:get:error aborted after 0 millis > > does anyone know what's going on here? > > ciao, > tobi
Hi Hannes,
I've had a quick look at jala.Form: It looks very promising! And yes, let's bundle the efforts. I don't really know if i get you idea of decentralization/centralization right. Let me explain it from my point of view. What I want is a central (typed) data model, that can be used to automatise/ease most of the common web developer tasks. It should be designed the way, that you only have to define that model add some CSS and will have the most basic input/output/data handling functionality ready. (Maybe it would be better to implement sth. like that in helma core) This should be as easy as possible and is centralized for that reason. I think the point is, how to enable specialisation of this basic functionality. The different tasks like data validation, form rendering etc. can then be handled decentralized by specialised classes - no problem with that. (A
s long as the user don't have to install dozens of libs because of all the dependencie
s ;) )
There is no db evolution/versioning in the rocket.Db. What would be the reason to put implement this?
To start the modelling from an existing db is in fact a process I also thought of and is not implemented yet only because of a shortage of time.
So where should this evolve to? I would like to see Rocket combined with more elaborated form/output generation/validation and skinability. Maybe someone will need/add support for other DBs? I don't know if it's in the scope - but maybe it is an idea to think of Ajax input/output support.
On the long run I would like to see some of this functionality included in a cleaned Helma core itself. It should then be possible to prototype Helma-Apps from scratch up to the most elaborated Ajax functionality. There is so much momentum in the Javascript/Ajax development. Sadly ROR is the big player on the server side development. But with the right efforts, maybe Helma could catch up.
BTW: Is there any chance to see the ECMAScript 4 standard implemented in Rhino some time?
Samuel
Hi Samuel,
I just skimmed through the code quickly. It's definitely interesting.
I think I would prefer a less decentralized approach, meaning I don't
think that database design and html form generation/handling should be
defined in the same spot. But it's a matter of taste, really.
For the form handling stuff you may also want to check out what's
going on in jala: there's a jala.Form module which I think will be
part of the next major release:
https://opensvn.csie.org/traccgi/jala/wiki/JalaModules/Form
https://opensvn.csie.org/jala/trunk/docs/jala.Form.html
https://opensvn.csie.org/traccgi/jala/ticket/39
I think it may make sense to combine this with what you're doing.
For my part, I'm especially interesteed in the database features you
have in there. Is there any kind of versioning/db evolution support in
there? Support for starting from an existing database? In what
direction, if any, would you like to see this evolve?
Hannes
29 Apr 2007 09:02:24 -0000, Samuel Oey < sam <at> sumaato.net>:
> Hello List,
>
> I discovered Rabbit some weeks ago and really like to push the prototyping
> idea. Here is what I worked on my spare time the last weeks. In large parts
> it's based on Rabbit, but I break the code appart in different parts and
> introduced some new stuff. Grab the code and do with it whatever you want.
> I'm hoping for discussions and some interest in boosting the helma
> development process.
>
> Pick the source here:
>
> http://typolis.net/developer/stories/12133/
>
> Features:
>
> * Metadata for Hop Object prototypes
> * Automatic form/input generation
> * DB/Table generation (MySql)
> * Creation of the model from existing source
> * Creation of folders/type.properties from the model
> * Basic permission management/access control
> * Basic List / Object viewer
>
> _______________________________________________
> Helma-user mailing list
> Helma-user <at> helma.org
> http://helma.org/mailman/listinfo/helma-user
>
_______________________________________________
Helma-user mailing list
Helma-user <at> helma.org
http://helma.org/mailman/listinfo/helma-user
_______________________________________________ Helma-user mailing list Helma-user <at> helma.org http://helma.org/mailman/listinfo/helma-user
Hi Samuel and list, > The different tasks like data validation, form rendering etc. can then > be handled decentralized by specialised classes - no problem with > that. (As long as the user don't have to install dozens of libs > because of all the dependencie s ;) ) I released a working (but not actively developed anymore, so probably clean-up and Helma specific updates needed) framework capable of doing would you describe above quite some time ago. It is based on a central xml file (configuring prototypes and properties validation) and decentralized xml files for each prototype describing form rendering. As far as I know the download site doesn't exist anymore, but feel free to send my an off-list email to hear more about it or to get it. > To start the modelling from an existing db is in fact a process I also > thought of and is not implemented yet only because of a shortage of time. Did you see my warp repository (see helma-dev mailing list)? This is probably the most easiest way to start of Helma prototyping from an existing db. > What I want is a central (typed) data model, that can be used to > automatise/ease most of the common web developer tasks. It should be > designed the way, that you only have to define that model add some CSS > and will have the most basic input/output/data handling functionality > ready. > [...] > There is so much momentum in the Javascript/Ajax development. Sadly > ROR is the big player on the server side development. But with the > right efforts, maybe Helma could catch up. This sounds very similar to what I want to work on in the near future, although my approach is more academic and will not be Helma-based but using Helma as one of many web application framework alternatives. I am not sure if anybody of you ever heard of Executable UML (little development and research effort so far), did you? Its an approach to cut the development effort for medium and big sized projects, keep modeling in sync with development, increase re usability and to develop without much architectural thinking. In the most ideal case, software development - or in the special case we are all interested in which is web-development - the development effort is decreased to the point where you only need to model your web application using UML using specialised UML profiles. Once the modeling process is done, web application development should be finished and the model should be directly executable with for example Helma as so called model compiler. And now imagine: The database gets created and is kept in sync by the configured database model compiler (i.e. MySQL) The web application gets created and is kept in sync by the configured logic model compiler (i.e. Helma) and so on... Helma update from 1.x to 2.0? "Downgrade" (-; to PHP? Convert to a Java GUI application? Just change your model compiler! Well, this is the big idea - I won't be finished by tomorrow although (-; The really important thing about that all related to Helma is that the first available model compiler of course will be Helma and one other. So this wouldn't only help Helma to just catch up with RoR but maybe overtake it by some steps (-; Greetings, Daniel
Hi Samuel, 2007/5/4, Samuel Oey <sam <at> sumaato.net>: > Hi Hannes, > > I've had a quick look at jala.Form: It looks very promising! And yes, let's > bundle the efforts. I don't really know if i get you idea of > decentralization/centralization right. Let me explain it from my point of > view. What I want is a central (typed) data model, that can be used to > automatise/ease most of the common web developer tasks. It should be > designed the way, that you only have to define that model add some CSS and > will have the most basic input/output/data handling functionality ready. Yes, that's wonderful, I share most of what you describe. Where my view differs is mostly in how much to put into the extended type.properties: data definition stuff yes, but I'm not sure about the validation stuff, and even less the html form element description. I would just prefer to have them in another layer, probably expressed in JavaScript code rather than a properties file. But then, maybe all this should and could be expressed in JavaScript rather than type.properties (there's no reason we can't have a JS API for type mapping/model description), so that objection would vanish. I also think that the automatically generated interface should be thought of as admin interface, with the possibility to create the "real" interface from scratch (see below). > (Maybe it would be better to implement sth. like that in helma core) This > should be as easy as possible and is centralized for that reason. I think I don't think so. Helma core should provide the necessary means (i.e. API), but it's nice to have the details in JS. > the point is, how to enable specialisation of this basic functionality. The > different tasks like data validation, form rendering etc. can then be > handled decentralized by specialised classes - no problem with that. (As > long as the user don't have to install dozens of libs because of all the > dependencie s ;) ) Yes, I agree, see above. As I said above, it's also possible that the automatic GUI would just be treated as admin interface for basic CRUD operations (create, read, update, delete). The real/public interface would be handcoded, of course building on some powerful modules (possibly the same used by the admin interface). I think this is the way it's done in the Django framework. > There is no db evolution/versioning in the rocket.Db. What would be the > reason to put implement this? Oh, just a question. Databases schemas evolve, and so it's nice to have some support for that. Somethign I've seen elsewhere evolves up() and down() scripts to automatically move database schemas up and down the evolutionary scale. > To start the modelling from an existing db is in fact a process I also > thought of and is not implemented yet only because of a shortage of time. > > So where should this evolve to? I would like to see Rocket combined with > more elaborated form/output generation/validation and skinability. Maybe > someone will need/add support for other DBs? I don't know if it's in the > scope - but maybe it is an idea to think of Ajax input/output support. > > On the long run I would like to see some of this functionality included in a > cleaned Helma core itself. It should then be possible to prototype > Helma-Apps from scratch up to the most elaborated Ajax functionality. Yes, sure. Your help to get us there is welcome! > is so much momentum in the Javascript/Ajax development. Sadly ROR is the big > player on the server side development. But with the right efforts, maybe > Helma could catch up. > > BTW: Is there any chance to see the ECMAScript 4 standard implemented in > Rhino some time? Some people are thinking about it. Don't expect it in the near future. hannes > > Samuel > > 2007/4/30, Hannes Wallnoefer <hannes <at> helma.at >: > > Hi Samuel, > > > > I just skimmed through the code quickly. It's definitely interesting. > > I think I would prefer a less decentralized approach, meaning I don't > > think that database design and html form generation/handling should be > > defined in the same spot. But it's a matter of taste, really. > > > > For the form handling stuff you may also want to check out what's > > going on in jala: there's a jala.Form module which I think will be > > part of the next major release: > > > https://opensvn.csie.org/traccgi/jala/wiki/JalaModules/Form > > https://opensvn.csie.org/jala/trunk/docs/jala.Form.html > > https://opensvn.csie.org/traccgi/jala/ticket/39 > > I think it may make sense to combine this with what you're doing. > > > > For my part, I'm especially interesteed in the database features you > > have in there. Is there any kind of versioning/db evolution support in > > there? Support for starting from an existing database? In what > > direction, if any, would you like to see this evolve? > > > > Hannes > > > > 29 Apr 2007 09:02:24 -0000, Samuel Oey < sam <at> sumaato.net>: > > > Hello List, > > > > > > I discovered Rabbit some weeks ago and really like to push the > prototyping > > > idea. Here is what I worked on my spare time the last weeks. In large > parts > > > it's based on Rabbit, but I break the code appart in different parts and > > > introduced some new stuff. Grab the code and do with it whatever you > want. > > > I'm hoping for discussions and some interest in boosting the helma > > > development process. > > > > > > Pick the source here: > > > > > > http://typolis.net/developer/stories/12133/ > > > > > > Features: > > > > > > * Metadata for Hop Object prototypes > > > * Automatic form/input generation > > > * DB/Table generation (MySql) > > > * Creation of the model from existing source > > > * Creation of folders/type.properties from the model > > > * Basic permission management/access control > > > * Basic List / Object viewer > > > > > > _______________________________________________ > > > Helma-user mailing list > > > Helma-user <at> helma.org > > > http://helma.org/mailman/listinfo/helma-user > > > > > _______________________________________________ > > Helma-user mailing list > > Helma-user <at> helma.org > > http://helma.org/mailman/listinfo/helma-user > > > > > > _______________________________________________ > Helma-user mailing list > Helma-user <at> helma.org > http://helma.org/mailman/listinfo/helma-user > >
Hi I have actually the same problem too. It would be great if there is a solution. greetings elias On 4/20/07, VividVisions, Walter Krivanek <walter.krivanek <at> vividvisions.at> wrote: > Hi, > > do you know, how I can send custom error messages to XML-RPC clients? > I tried throwing an exception but then the client receives a message > like "helma.scripting.ScriptingException: That's my message. (/usr/ > local/helma-1.6/apps/myApp/API/Actions.js#23)" in the error object > which is a bit too much of an insight. So, is there a way, that the > client only gets "That's my message." ? > > Thanks! > Walter
is it normal that:
public static String convertHac(Resource action) throws IOException {
String functionName = action.getBaseName().replace('.', '_') +
"_action";
return composeFunction(functionName, null, action.getContent());
}
but action.getContent(charset) take the charset, and so the files are readed
from the disk as iso-8859-1, and i have files in utf8...
all seems strange to me, in fact hard coding (not a good way but just to
show you):
public static String convertHac(Resource action) throws IOException {
String functionName = action.getBaseName().replace('.', '_') +
"_action";
return composeFunction(functionName, null,
action.getContent("UTF-8"));
}
now i don't get any more strange characters if i have source .hac in UTF-8
(which i normally do)
--
--
View this message in context: http://www.nabble.com/charset-and-encodings-tf3714850s2589.html#a10397355
Sent from the Helma - User mailing list archive at Nabble.com.
what about adding a hacCharset and jsCharset property in app.properties ? (along with skinCharset and charset) ? -- -- View this message in context: http://www.nabble.com/charset-and-encodings-tf3714850s2589.html#a10397388 Sent from the Helma - User mailing list archive at Nabble.com.
RSS Feed1 | |
|---|---|
2 | |
8 | |
1 | |
21 | |
31 | |
13 | |
16 | |
32 | |
27 | |
21 | |
39 | |
23 | |
34 | |
8 | |
16 | |
46 | |
69 | |
24 | |
57 | |
56 | |
56 | |
36 | |
35 | |
26 | |
25 | |
47 | |
25 | |
77 | |
6 | |
57 | |
69 | |
12 | |
76 | |
39 | |
124 | |
33 | |
53 | |
18 | |
32 | |
71 | |
21 | |
15 | |
47 | |
8 | |
19 | |
22 | |
5 | |
6 | |
12 | |
12 | |
28 | |
7 | |
2 | |
27 | |
39 | |
52 | |
33 | |
25 | |
45 | |
69 | |
16 | |
24 | |
58 | |
34 | |
90 | |
74 | |
47 | |
79 | |
77 | |
41 | |
51 | |
75 |