Re: [GSoC] status reports?
I still got the same error. Anyway I put my code at: http://s91681504.onlinehome.us/gsoc/zooloon.tar.gz Please download from there. I'll figure out what's wrong with svn access tomorrow. -Heh On 9/1/05, Antonio Gallardo [EMAIL PROTECTED] wrote: Heh wrote: Please, check out the sources into : https://svn.apache.org/repos/asf/cocoon/whiteboard/forms-xul Sorry. I believe you have access to : https://svn.apache.org/repos/asf/cocoon/gsoc/ Please try: https://svn.apache.org/repos/asf/cocoon/gsoc/heh or https://svn.apache.org/repos/asf/cocoon/gsoc/forms-xul If any of them works, then please fill a new bugzilla report with an attachment. Best Regards, Antonio Gallardo
Re: [GSoC] status reports?
Hi Heh, On 2 Sep 2005, at 07:51, Heh wrote: Anyway I put my code at: http://s91681504.onlinehome.us/gsoc/zooloon.tar.gz Please download from there. I'll figure out what's wrong with svn access tomorrow. As Antonio points out, the best way of distributing your code is to add it to Cocoon's Bugzilla, as an attachment. This is the way everyone in the community without SVN access is encouraged to work with Cocoon, as it means the code is never lost (in case your server goes down with the thousands of Cocooners downloading it!), and that we get a reminder it is there from Bugzilla. You can find Bugzilla at http://issues.apache.org/bugzilla/ ... it would be a really good idea for you to use it. Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: [GSoC] status reports?
I reported a bug and attached the code zooloon-preview.tar.gz: http://issues.apache.org/bugzilla/show_bug.cgi?id=36472 Thanks for the suggestion! -Heh On 9/2/05, Andrew Savory [EMAIL PROTECTED] wrote: Hi Heh, On 2 Sep 2005, at 07:51, Heh wrote: Anyway I put my code at: http://s91681504.onlinehome.us/gsoc/zooloon.tar.gz Please download from there. I'll figure out what's wrong with svn access tomorrow. As Antonio points out, the best way of distributing your code is to add it to Cocoon's Bugzilla, as an attachment. This is the way everyone in the community without SVN access is encouraged to work with Cocoon, as it means the code is never lost (in case your server goes down with the thousands of Cocooners downloading it!), and that we get a reminder it is there from Bugzilla. You can find Bugzilla at http://issues.apache.org/bugzilla/ ... it would be a really good idea for you to use it. Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: [GSoC] status reports?
Hi Antonio, neither heh nor forms-xul exists under https://svn.apache.org/repos/asf/cocoon/gsoc/, I can't create the directory by my own, would someone help? -Heh On 9/1/05, Antonio Gallardo [EMAIL PROTECTED] wrote: Heh wrote: Please, check out the sources into : https://svn.apache.org/repos/asf/cocoon/whiteboard/forms-xul Sorry. I believe you have access to : https://svn.apache.org/repos/asf/cocoon/gsoc/ Please try: https://svn.apache.org/repos/asf/cocoon/gsoc/heh or https://svn.apache.org/repos/asf/cocoon/gsoc/forms-xul If any of them works, then please fill a new bugzilla report with an attachment. Best Regards, Antonio Gallardo
Re: [GSoC] status reports?
Please, check out the sources into : https://svn.apache.org/repos/asf/cocoon/whiteboard/forms-xul Hi Antonio, I tried to commit to the location above, but failed: svn: Commit failed (details follow): svn: CHECKOUT of '/repos/asf/!svn/ver/226495/cocoon/whiteboard': authorization failed (https://svn.apache.org) I'll provide a link for you to download my code. -Heh
Re: [GSoC] status reports?
Heh wrote: Please, check out the sources into : https://svn.apache.org/repos/asf/cocoon/whiteboard/forms-xul Hi Antonio, I tried to commit to the location above, but failed: svn: Commit failed (details follow): svn: CHECKOUT of '/repos/asf/!svn/ver/226495/cocoon/whiteboard': authorization failed (https://svn.apache.org) I'll provide a link for you to download my code. Better add a bugzilla report an include an attachment. Best Regards, Antonio Gallardo.
Re: [GSoC] status reports?
Heh wrote: Please, check out the sources into : https://svn.apache.org/repos/asf/cocoon/whiteboard/forms-xul Sorry. I believe you have access to : https://svn.apache.org/repos/asf/cocoon/gsoc/ Please try: https://svn.apache.org/repos/asf/cocoon/gsoc/heh or https://svn.apache.org/repos/asf/cocoon/gsoc/forms-xul If any of them works, then please fill a new bugzilla report with an attachment. Best Regards, Antonio Gallardo
Re: [GSoC] status reports?
The ordering issues are fairly simple to describe. I can't make XSLT do what I want. Most likely because I'm not too familiar with it. I have snippets (many of them) in a file with attributes of key, type, and name. I'd like to order them by type first which I've done. The snippets that have the same name attribute, however, are related to each other and should be ordered adjacent to each other. I can't see how to get each (snippet name=XXX) with the same name attribute to stick together without knowing the name attributes I'm interested in beforehand. (look at ordering-neutral.xsl) Robert, without having looked at your code, in XSL you can do a sort: xsl:for-each select=//snippet xsl:sort select=@myattribute/ xsl:sort select=@mysubsortattribute/ /xsl:for-each Have you tried replacing '@myattribute' with '@*'? I cannot test it right now, so I have no idea if this is going to work, but it's just an idea. Bye, Helma
RE: [GSoC] status reports?
Hi all! Well, I admit I am a bit behind, in a way. I have a strict plan by which I should be done by friday morning/thursday night ;) Progress-wise, I did everything preliminary. Partial widget definitions are possible and checked for completeness just before instantiation. I cleaned up the code a bit in general and I implemented a new component to manage libraries and look them up much like the FormManager. What's left is testing this library feature and inheritance. I decided to drop the Macro stuff in favor of New/Class which basically has the same functionality. Inheritance (when I'm done) will be available for _every_ widget, so you can even use it without using libraries at all. I had some problems, mostly unrelated to programming though. I planned the time so that I would work on it intensely in August, and just last week I had a bad flu and was sleeping basically for the whole week. I lost valuable time during that week, but as I said before, I have a plan and I just love it when a plan comes together! - John Hannibal Smith. ;) Steps until The End: 1. Test the ImportDefinitionBuilder/Library stuff, probably by use of a sample 2. Fix caching (done by the LibraryManager) to use timestamps as well so that forms know their dependencies have changed 3. Implement inheritance by copyconstructor. Builders are already modified to interpret configs as sensible as possible (i.e. merging display data instead of completely resetting it) 4. Binding Library: Model stuff is applicable, so port it 5. Template Library: Can't do much here, just provide inclusion mechanism for Class templates. 6. Oh, and docs of course... Phew, I did say it would be a tight plan, right? 1,2, and half 3 should be done by tonight/tomorrow morning, 4 tomorrow night, 5/6 thursday night. Then I will be on holiday until tuesday, and I'll have the 31st to wrap up anything that is still left. Okay, back to work! max -Original Message- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sent: Monday, August 22, 2005 08:55 To: dev@cocoon.apache.org Subject: [GSoC] status reports? With ten days left to finish the GSoC projects, I think it would be good for our three students to provide a short status report here. Think 3P: Progress: What have you accomplished and how does it compare to the project's goals. Problems: Is anything preventing you from reaching the project goals, and if yes can we do something about it. Perspectives: What are your plans until the September 1st pencils down deadline. Make sure to leave sufficient time for feedback where you need it. -Bertrand
Re: [GSoC] status reports?
Hi, The start of the project was much slower than i planned it to be. Cocoon and Lenya are more difficult to comprehend than i could imagine. Therefor it took a while before i came productive. The usecases for the searching, indexing and removing of documents are done. They work quite fast and are integrated in Lenya pretty neat. The calling of these usecases from another usecase is still a problem. I have used the UsecaseCronjob code as an example, but are still not sure why it isn't working the way it should. A debugging session will probably solve this problem. The integration of Nutch has moved to the background, i am afraid. I will have to concentrate on this in the last week to meet the project's goals. My intention is to leave the Nutch package as autonomous as possible and only use the index of as a secondary search engine. This can be done without much problems. The big remaining issue is the scheduling of the Nutch crawler. I must build a usecase that invokes the crawling of the publication and its external links, which can be invoked with the UsecaseCronjob. Some help or examples on this issue would be very welcome! Regards, Robert Bertrand Delacretaz wrote: With ten days left to finish the GSoC projects, I think it would be good for our three students to provide a short status report here. Think 3P: Progress: What have you accomplished and how does it compare to the project's goals. Problems: Is anything preventing you from reaching the project goals, and if yes can we do something about it. Perspectives: What are your plans until the September 1st pencils down deadline. Make sure to leave sufficient time for feedback where you need it.
Re: [GSoC] status reports?
On 8/22/05, Robert Graham [EMAIL PROTECTED] wrote: snip/ The ordering issues are fairly simple to describe. I can't make XSLT do what I want. Most likely because I'm not too familiar with it. I have snippets (many of them) in a file with attributes of key, type, and name. I'd like to order them by type first which I've done. The snippets that have the same name attribute, however, are related to each other and should be ordered adjacent to each other. I can't see how to get each (snippet name=XXX) with the same name attribute to stick together without knowing the name attributes I'm interested in beforehand. (look at ordering-neutral.xsl) I'm also notablet to look at the code at the moment, but there are likely two possibilities here. First, as Helma points out, you can add a second sort instruction: xsl:for-each select=//snippet xsl:sort select=@type/ xsl:sort select=@name/ I do not believe doing a sort select=@* will work. In some cases I end up constructing the select statement on the fly and using eval extension to turn it into proper sort order. Eg: xsl:variable name=sortcmdsome complicated logic.../xsl:variable xsl:for-each select=//snippet.. xsl:sort select=exslt:eval($sortcmd) .../ Obviously that's not optimum since it isn't completely portable, but it is powerful. In particular, you can build look up tables that tell you how to sort on various types, index into them, and build your resultant sort. The second possibility is that you really have a grouping problem and that you want to group first, then sort on the grouped results. There are all kinds of resources on XSLT grouping; the Mulberry XSLT list has dozens of FAQ's and archived mailings on it (some from me asking strange grouping questions). If you think this approach may be more fruitful you can ask more here or there... -- Peter Hunsberger
Re: [GSoC] status reports?
Thanks for the ideas...they may have given me a solution. I'm still not familiar enough with XSLT to really think with it or in it, but such ideas can give me a spark. I'll be more specific about the problem and lay out my quick idea for a solution. Then everyone can ridicule my hole-ridden solution and give me better ideas. =) So we have a collection of snippets with the same key attribute. These snippets can have many types: sitemap-param component-param name description details warnings see-also etc. In addition to the type attribute, I have given them an optional name attribute. This means that a snippet of type=name and another of type=description can be linked together under the name=XHTML Generator or some other such categorical designation. This linking is for the publishing aspect of things where we need to create a document that has meaningful structure and layout that can be displayed on the fly off of a search. So for publishing I had the idea to follow something of a Javadoc layout and give the document structure with a name at the top followed by a description, details, warnings, and see-also. However, elements of all types with a name attribute that isn't the null string should all be grouped together. Ex: snippet type=name ... /snippet snippet type=description ... /snippet snippet type=see-also ... /snippet snippet type=name name=XComponent ... /snippet snippet type=description name=XComponent ... /snippet snippet type=sitemap-example name=XComponent ... /snippet snippet type=name name=YComponent ... /snippet snippet type=description name=YComponent ... /snippet snippet type=sitemap-example name=YComponent ... /snippet Hope that clarifies the problem. Thanks, Robert
Re: [GSoC] status reports?
snip/ So for publishing I had the idea to follow something of a Javadoc layout and give the document structure with a name at the top followed by a description, details, warnings, and see-also. However, elements of all types with a name attribute that isn't the null string should all be grouped together. Ex: snippet type=name ... /snippet snippet type=description ... /snippet snippet type=see-also ... /snippet snippet type=name name=XComponent ... /snippet snippet type=description name=XComponent ... /snippet snippet type=sitemap-example name=XComponent ... /snippet snippet type=name name=YComponent ... /snippet snippet type=description name=YComponent ... /snippet snippet type=sitemap-example name=YComponent ... /snippet Hope that clarifies the problem. Unless I',m missing something that looks like a simple two order sort should work: xsl:for-each... xsl:sort select=@name/ xs:sort select='@type/ You could also try playing tricks with concatinating the attributes: xsl:for-each... xsl:sort select=concat(@name, '-', @type)/ Depending on what you choose as the attribute separator (the dash '-', above) you can then either force the elements without a name attribute to come first or last... -- Peter Hunsberger
Re: [GSoC] status reports?
Since last discussion, I've been working on how to use rdf data source and xul template to populate XUL widgets, how to connect to cocoon using XMLHttpRequest and update widgets through js scripts. So far I am able to create simple examples to demonstrate those techniques (will be detailed in documents). Issues: (1) XUL template XUL template is hard to work with, it's a black box, no error reporting, all silient failures. You never know if the failures come from incorrectly formatted rdf file, or rdf file not loaded at all, or the template predicates unmatched, or the illegal template actions? I googled around, there seems no useful supporting tools for XUL tempate, and for a few times this top-ranked rants about xul template showed up: http://www.jerf.org/resources/xblinjs/whyNotMozilla/notXulTemplates.html it recommeded to use mozilla JSLib to control the behavior of XUl widgets, I was thinking about that, what do u think? (by the way, what's Apache's policy regarding including other free/open source code?) (2) CForms Browser Update mechanism how to extend this beautiful BU mechanism to handle XUL widgets? Currently the examples I've been working on are all standalone, which means that the xul file is delivered on cocoon as it is by map:read/, not through pipeline, pieces of js scripts have been written to handle the widget behaviors. While the BU mechanism is tied to the cforms widgets (correct me if i am wrong), to utilize the BU or the ajax support, the xul widgets has to be transformed to the cform widgets to be recognized by the system, i tried to modify these files: forms-page-styling.xsl forms-advanced-field-styling.xsl forms-field-styling.xsl forms-samples-styling.xsl simple-page2html.xsl but no luck, I don't know to handle those fields with atributes like onchange, also the set of xul widgets are asymmetric to the cform ones. (3) Project release when the due day is up, what's the procedure to release the project? Future: this GSoC project is just a beginning, that's for fure. During these days, I learned a lot, also found out there are lots of things worthy to do, the momentum has been built, I don't want to lose it. This project is about XUL and CForms, going forward I think it's more nature to continue to work on the cocoon XUL support as a separate new block, the reason is, just briefly put here, the CForms is designed to hand UI on the backend, while XUL is on the frond end, to mix them up is like to put one interface on another, it's just too much. This is just my own opion based on what I've learned from working on this project. Open for discussion of course. -Heh On 8/21/05, Bertrand Delacretaz [EMAIL PROTECTED] wrote: With ten days left to finish the GSoC projects, I think it would be good for our three students to provide a short status report here. Think 3P: Progress: What have you accomplished and how does it compare to the project's goals. Problems: Is anything preventing you from reaching the project goals, and if yes can we do something about it. Perspectives: What are your plans until the September 1st pencils down
Re: [GSoC] status reports?
Hello Heh, On 24.08.2005 00:39, Heh wrote: Since last discussion, I've been working on how to use rdf data source and xul template to populate XUL widgets, how to connect to cocoon using XMLHttpRequest and update widgets through js scripts. So far I am able to create simple examples to demonstrate those techniques (will be detailed in documents). Issues: (1) XUL template XUL template is hard to work with, it's a black box, no error reporting, all silient failures. You never know if the failures come from incorrectly formatted rdf file, or rdf file not loaded at all, or the template predicates unmatched, or the illegal template actions? I googled around, there seems no useful supporting tools for XUL tempate, and for a few times this top-ranked rants about xul template showed up: http://www.jerf.org/resources/xblinjs/whyNotMozilla/notXulTemplates.html it recommeded to use mozilla JSLib to control the behavior of XUl widgets, I was thinking about that, what do u think? in open source you are almost never the only or the first one fighting with a problem. For the XUL templates you could have asked either in the Mozilla community or here. We have started a XUL project 3 years ago and I have also fought *very* much with XUL templates. I don't know about JSLib, but I used the DOM inspector heavily that is delivered with Mozilla (don't know about Firefox). With it you can see at least what the source of failure is, though not why. Yeah, working with XUL templates was always like walking in a dark foggy night through an unknow country :) But the application is still running, in production use (though not publicly) and maintained. (by the way, what's Apache's policy regarding including other free/open source code?) This heavily depends on the other software's license. It must be compatible to the Apache License. (2) CForms Browser Update mechanism how to extend this beautiful BU mechanism to handle XUL widgets? Currently the examples I've been working on are all standalone, which means that the xul file is delivered on cocoon as it is by map:read/, not through pipeline, pieces of js scripts have been written to handle the widget behaviors. While the BU mechanism is tied to the cforms widgets (correct me if i am wrong), to utilize the BU or the ajax support, the xul widgets has to be transformed to the cform widgets to be recognized by the system, i tried to modify these files: forms-page-styling.xsl forms-advanced-field-styling.xsl forms-field-styling.xsl forms-samples-styling.xsl simple-page2html.xsl but no luck, I don't know to handle those fields with atributes like onchange, also the set of xul widgets are asymmetric to the cform ones. The question is not very specific, but most of the information of the form instance must go to the client (in rdf format). The above stylesheets should be that much involved, the structure of them is probably not appropriate. Probably only one stylesheet transforming form instance XML representation to RDF would be sufficient. For a real AJAX-like handling it gets more complicated of course. (3) Project release when the due day is up, what's the procedure to release the project? You have a svn account to commit your stuff. Future: this GSoC project is just a beginning, that's for fure. During these days, I learned a lot, also found out there are lots of things worthy to do, the momentum has been built, I don't want to lose it. This project is about XUL and CForms, going forward I think it's more nature to continue to work on the cocoon XUL support as a separate new block, the reason is, just briefly put here, the CForms is designed to hand UI on the backend, while XUL is on the frond end, to mix them up is like to put one interface on another, it's just too much. This is just my own opion based on what I've learned from working on this project. Open for discussion of course. I don't see we need another block, but that might evolve. For the moment I think it's appropriate to put it besides the HTML stuff, starting (as HTML) in the samples section maybe. Joerg
Re: [GSoC] status reports?
Hi Heh: Joerg already answered the questions. Just some ideas between lines. Heh wrote: Since last discussion, I've been working on how to use rdf data source and xul template to populate XUL widgets, how to connect to cocoon using XMLHttpRequest and update widgets through js scripts. So far I am able to create simple examples to demonstrate those techniques (will be detailed in documents). Issues: (1) XUL template XUL template is hard to work with, it's a black box, no error reporting, all silient failures. You never know if the failures come from incorrectly formatted rdf file, or rdf file not loaded at all, or the template predicates unmatched, or the illegal template actions? I googled around, there seems no useful supporting tools for XUL tempate, and for a few times this top-ranked rants about xul template showed up: http://www.jerf.org/resources/xblinjs/whyNotMozilla/notXulTemplates.html it recommeded to use mozilla JSLib to control the behavior of XUl widgets, I was thinking about that, what do u think? (by the way, what's Apache's policy regarding including other free/open source code?) It depends. under wich license is released JSLib? I found the site, but I was not able to find the license: http://jslib.mozdev.org/ BTW, MPL 1.1 is OK. MPL 1.0 is NOT OK. (2) CForms Browser Update mechanism how to extend this beautiful BU mechanism to handle XUL widgets? Currently the examples I've been working on are all standalone, which means that the xul file is delivered on cocoon as it is by map:read/, not through pipeline, pieces of js scripts have been written to handle the widget behaviors. While the BU mechanism is tied to the cforms widgets (correct me if i am wrong), to utilize the BU or the ajax support, the xul widgets has to be transformed to the cform widgets to be recognized by the system, i tried to modify these files: forms-page-styling.xsl forms-advanced-field-styling.xsl forms-field-styling.xsl forms-samples-styling.xsl simple-page2html.xsl but no luck, I don't know to handle those fields with atributes like onchange, also the set of xul widgets are asymmetric to the cform ones. Since there is no much time left and Joerg told AJAX is a quite complex issue. I will recomend to drop the AJAX support. (I hope Joerg agree with this decision too). Please, check out the sources into : https://svn.apache.org/repos/asf/cocoon/whiteboard/forms-xul (3) Project release when the due day is up, what's the procedure to release the project? Future: this GSoC project is just a beginning, that's for fure. During these days, I learned a lot, also found out there are lots of things worthy to do, the momentum has been built, I don't want to lose it. You can stay in the community after GSoC. We welcome you! This project is about XUL and CForms, going forward I think it's more nature to continue to work on the cocoon XUL support as a separate new block, the reason is, just briefly put here, the CForms is designed to hand UI on the backend, while XUL is on the frond end, to mix them up is like to put one interface on another, it's just too much. This is just my own opion based on what I've learned from working on this project. Open for discussion of course. As Joerg, I don't see the need for a new block. There was an RT with the idea of support XForms [1] UI too. Don't worry, I am not going to include this in your project. ;-) No matter if we will support XForms again (see mails since 2000 [2]) through cforms. The point is to enable Cforms to support different UIs. [1] http://www.w3.org/MarkUp/Forms/ [2] http://marc.theaimsgroup.com/?l=xml-cocoon-devr=1s=xformq=b Best Regards, Antonio Gallardo
Re: [GSoC] status reports?
On 22.08.2005, at 08:55, Bertrand Delacretaz wrote: With ten days left to finish the GSoC projects, I think it would be good for our three students to provide a short status report here. +1 cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: [GSoC] status reports?
Hello all, Let me preface this by saying that I've really enjoyed this project and everything that I've learned. I hope, time constraints under my studies permitting, that I can continue to be a community member. I'm working hard at the end to wrap it up and I think that it looks something like the final goal for this project. Progress: I have taught myself XSLT and learned a lot about Cocoon. I've even picked up some information about SAX processing (I've really only got previous experience with DOM). Though that has little to do with the project's goals except that I have to be the achiever. I have expanded the prototype code that Bertrand gave me in fixing bugs, creating functionality that we needed for the project, and learning about the technologies. The system now can be pointed at any directory with little effort and used to create an index of doktor comments that can even be searched. The app can generate an xml stream enumerating only those snippets that correspond to the searched for key and order them in an unsatisfactory but better than no order sort of way. Problems: I am not sure of issues in ordering the items with XSLT which I will address in more detail in a moment. Hopefully I can get some feedback and ideas on how to implement that. The last thing is simply that we don't have a lot of time left and I'd like to finally publish something detailing the work as it is and as it should be using the system itself, but I'm not familiar with Forrest and even if I liked the current state of the system I doubt I could create the desired publication without guide and in time unless Forrest is far simpler than Cocoon. The ordering issues are fairly simple to describe. I can't make XSLT do what I want. Most likely because I'm not too familiar with it. I have snippets (many of them) in a file with attributes of key, type, and name. I'd like to order them by type first which I've done. The snippets that have the same name attribute, however, are related to each other and should be ordered adjacent to each other. I can't see how to get each (snippet name=XXX) with the same name attribute to stick together without knowing the name attributes I'm interested in beforehand. (look at ordering-neutral.xsl) The last issue I have is a bug I haven't been able to solve. Sometimes in the way of processing the comments and indexing them and them grabbing the stored fields and processing them again I lose the actual comment contents and haven't been able to locate this bug. I think Bertrand may know what the issue is, however, as I think it has something to do with the way I interact with his prototype code. Perspectives: Hopefully get some initial feedback from this email while trying to solve the three issues above. If I can't solve them I will in parallel setup comments in the code I've written that will be there so I can generate publishable documentation for the project (the goal). I will then try to use Forrest and whatever other tools to get it into a reasonable published form. The issues are in my mind from most to least important: publishing, ordering, content bug (as I think the solution to the last is simple, but hard for me to see) I'd be happy to clarify anything or provide more information. I thank anyone who looks things over in advance for it and any help/advice they may offer. Thanks, Robert Graham
