Re: Cocoon portal and excel
Not specific on coplets, but, a submit button is embedded in a form. The form has an action target. This target should point to a sitemap component (pipeline). If you're in the pipeline, it's up to you to generate your XML using a generator, extracting information from the request. As I hear this, it looks like an action which is not matched by a pipeline component. You could look at the HTML sources in your browser to see where you are submitting to. If that's the same action as the URL, the you *could* try method=get in your form. Then the plain URL is reproduced. Using method=GETduring development is IMHO not that bad anyway, as you have more information readily at hand. Sorry I can't say more, but doesn't work is not really abundant information:) Do sitemap.log or access.log (cocoon/WEB-INF/logs) or localhost-[date].log (tomcat/logs) say anything? Leon Anna Bikkina wrote: Hi, I am using cocoon as a portal server. In one of my coplets when the user submits a form I want the output to be displayed in a excel file. When I have the excel operation in a submit button this doesnt work. If I use a hyperlink in the page with all information in the url then it works. Can anyone tell me how to generate an excel file as output for a coplet. I want the excel to be generated and the coplet should remain the same. Please let me know if there any way of doing this. Thanks, Anna.
Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
Stefano Mazzocchi wrote: Leszek Gawron wrote: Components are existed before Flow, but Flow is more popular than writing components, the question is why? flowscript + notepad vs. components + eclipse. and the winner concerning development lifecycle time is: flowscript. Flowscript is: a) scripted b) automatically reloaded by cocoon after changes without container restart. See? *this* is what I'm talking about. Now we made it easier to write flowscript than to write components, now we have to focus on making it easier to write components than flowscript. How? Chris' magic compiler classloader is the way to go, IMHO. From a users point of view: YES YES YES. I am now porting an application from pure flowscript to Java since I got a headache from looking at the 1000+ lines, 4000+ words flowscript based app. And this was only the framework for the business logic:) The reason I did this was actually because I didn't want my WEB-INF classes with application specific classes. And re-starting each time I test is also not preferred. I think if the compiler/classloader would have existed for flowscript I would just use that, as Java is very much simpler to develop and maintain. I think though, that some formal properties of a component (what makes a component a component) should be defined. A bit like the way JavaBeans are defined: A java bean has ...). Leon Given a choice, people would like to use eclipse for their business logic, I'm sure, give them autocompletion and autoreload and logic will start floating from flow to components. keep in mind that with real blocks any class is a component, so no reason to implement the avalon lifecycle if you don't want to.
Re: Modular database component
Joerg Heinicke wrote: On 20.04.2004 07:49, Reinhard Poetz wrote: Following this I don't see the need for a. calling DB from within Flowscripts You mean direct JDBC? Hmm.. I don't like the idea, but here Groovy can take the role a lot better than Javascript. Note, Groovy has built in SQL support and that is good. From Antonio's comment I guess he just misread your comment. To restate it: Reinhard does not want flow scripts calling DB. Yes, I don't like the idea too. It's good for prototyping but I wouldn't write my applications with direct DB calls from within the flow layer. I don't want direct DB calls from within Groovy as Flow language *also* because this mixes concerns!!! Same here. DB should not be called from flow script - neither JavaScript nor Groovy nor XYZ. The thing is about page flow. b. code CRUD in templates (Groovy, JXTemplate, ...) and XSP I will use this combination for (2) it is more powerful than the proposed. Also note, JXTG is useful in combination with CForms. It allow you to easy make a dynamic listbox or show a simple list report for users. It is really useful have JXTG at hand. I really like JXTG but for now it has *no* direct DB access. You have to pass the objects to the pipeline within cocoon.sendPage*() and this is good! Same here again. I wonder why templating languages shall be featured up with db access. What I want to tell all users clearly is that they should avoid writing SQL-statements. Integrating SQL in applications is the start of a maintainence nightmare and IMHO we should clearly warn them using XSP, Groovy or any other templating system requiring you to write SQL *into* the code. Once again, I really like e.g. JXTG but it should *never* contain SQL statements. IMO the same is true for Groovy scripts. +1 (to avoid writing same here again :) ) Joerg For beginning cocoon/flowscript users one should, if not providing direct SQL access, provide a well documented and above all for simple scenarions EASY way. Setting up and integrating either OJB and Hibernate do nut fullfill that condition yet. I also think that requiring Java classes to be pre-generated (and then included in the classpath) for even the simplest queries is not a problem for developers and advanced users, but is to much to ask for a user just starting who just wants to display his address data or something alike. I think it is unclean, classes should be put in the application. A way to describe/map the database using XML (as done by Hibernate and OJB both) should suffice - the rest should be done on the fly like with xsp. That is by far the easiest. For advanced uses where those classes are extended one could think of precompiled classes. The way to gain acceptance for a superior framework is to make it just as easy as using plain SQL IMHO. Nothing beats the simplicity at present of pure SQL access - for simple apps. Let's not make any new framework/component difficult to start with. Power should be available on demand, complexity postponed (Yes - someone told me it's an on demand world nowadays:) Leon
Re: Modular database component
Antonio Gallardo wrote: Reinhard Poetz dijo: I'm aware of the fact that there are many ways in Cocoon. I think that we as community should give clear advice what's in our opinion the best way. If I'm asked I say: 1. Enterprise Level --- O/R-mapping, EJB 2. Simple Database Applications with CRUD (create/update/delete) --- Flowscript and Database Component With Groovy the (2) will be easier. 3. Publishing--- SQLTransformer I think (2) can be also be used with O/R mapping tool. Not sure what the DB component is. In fact (and with my respect to ESQL developers) why Cocoon will need to build another layer when there is OJB. Remeber OJB allow you to play at 4 levels: As a user: Of course you can. The question is whether you'd want to. Using OJB seems to demand that you set up descriptions of the tables, then create appropriate classes etc. For a user, most of whom know a bit about SQL, or can read about it in the thousands of introductory level books, SQL is much easier, not to say more standard. Furthermore, creating a query based on form input is just the concatenation of Strings. How much more easy can it get? As an added bonus, you can just log the queries in the developer phase and cut-and-paste them in the command line database tool to see why they would not work. If you use an added layer that power would either be lost or more difficult accessible. I fully see that OJB is more beatifull. But not all people who wish to write a simple flowscript app wish to start learning two major technologies at once; they would fall back on a familiar technology where possible to decrease the chance of failure. I think more of providing an easy migration path from CRUD to OJB, using a MigrateFromCRUDToOJB Wiki page in which a simple CRUD flowscript is moved to the OJB framework, and a sketch of a situation where OJB is clearly easier to use that any other way. I think that, if you are familiar with OJB it is hard to see that things like hibernate and OJB seem daunting; even the name promisses sleepless nights. And who on earth needs a bridge or relational mapping for Select username, password from authentication where username = 'foo';? If you already have OJB up and running it is logical to use that, but to start learning OJB just for that??? Leon
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
snip/ But both such cases would be to protect the user, and not to force users to a certain development model favoured by the developer. The developer may well be right in his opinions, but users come from different backgrounds and would not understand they be limited because their way is not neat. I am sorry if this sounds to harsh, but it really *is* hard enough to find functions which do what you want them to do. If you then find out those functions are blocked for some unfathomable (ideologic) reason, you would not be glad. Well, given the fact that I wrote the bit you're responding to and not Guido I don't think he'll find it harsh ;-) Oops -- Sorry Guido:) I don't see much difference between marking something private vs. not for normal access by end users? In fact I think the RAD flag would be a little more liberal than private vs. public since if you needed you could always flag a script as using non-FOM objects, but if the object is private you're going to need the source of the Java object to make the change? It is not the flag in itself, it is the reason why you would apply it. private as in Java or C++ is used in general for internal helper functions. They tend to be very implementation dependent. A component that really does something also tends to have implementation specific functions. And I do not think it's bad if they stay hidden just *because* their contract tends to fluctuate over versions. So removing them from the namespace is to protect the user. And in that sense - if a function is private, you'd not want other objects to play with the component internals - at all. It may break the component. But it really could be that I misunderstood things. I understood that developers would make only a portion of the interface available to users, and another portion to developers. That seems quite artificial. Flagging a function needs to have a clear meaning, one readily understood by even the simplest of users (e.g. me). Strong potential to damage your environment, or your objects, as a side effect is something even I can understand. Maybe I can give a small example: You have a component which can transform a given string into a Base64 encoded, MD5 transformed String. An implementer could just provide the user interface (non-flagged) String convert(String). And hide the utility functions Byte[] md5(Byte[]), String Base64(Byte[]). That would be a shame since then everyone needing a Base64 would have to roll their own (or, in my case, copy-paste from the component source). The example is a bit artificial, and the syntax is disturbingly Java like:) but javascript does just not have the clear expressions to demonstrate what I want. On a side note: is it possible to split your javascript file into multiple files, each holding a class-like thingy and integrate them in the main flowscript, using e.g. cocoon.load( uri )? If I read to much in the statement above I am sorry. But I strongly feel that flow is a more powerfull technology than xsp for many applications, and that it should be kept simple for users. And simple is not a limited set of functions, but a feature rich environment which allows you to do what you want without to much Java (a bit like xsp is now), Personally, I tend to agree. However, if others feel the need to restrict the contract more than currently I think there should be some kind of escape hatch for developers... The developer writes the code. The developer owns the code. He or she can do with it what he or she likes. Fortunately, the people who write code for Cocoon seem to be very user-oriented (apart from naturally striving to elegant solutions which is I think quite common to all people who write software), so I'm quite confident that in the end all restrictions placed by developers will truly make sense. I just hope that that sense of the restriction translates into documentation in the source (yes - I do read the source. Grep and find are among my best friends:) Leon
Re: Modular database component
I will not be sure. Writing SQL code is always larger than using O/R mapping tools and we already know many developers have problem with SQL. They don't write optimal SQL queries. See slides 10-14: http://cvs.apache.org/viewcvs.cgi/*checkout*/db-ojb/contrib/ojb-dataccess.pdf I honestly do not care about the efficiency of my SQL. The database is by far the fastest component. I do not think OJB can really optimize a simple SELECT foo, bar from BLA; statement. There's just nothing to optimize! I do think that when queries get a bit complicated, or when columns or tables are related, such tools are much preferred to SQL as it is just to easy to forget to do something. I'm not argueing that. It's just the very simple stuff I'd like to keep simple. I have spent somehwat more than an hour now to try to get a mapping for my database auto-generated using the reverse-db tool of OJB. It just does not give me my table definitions. So now I search for another tool. All that takes time. Then comes a learning curve. And only then I can try to integrate it into my program into what amount to select fullname, username from auth where username='foo'; I think simple things should not large tools to handle. It only introduces other bugs. I think the SQL does not fit well into the OO world. That was told over and over. The O/R mapping gives you the hability to work with tables as Objects. As a sample, you can use JXPath and write something like: That's true. And javascript is not OO so the match is perfect:) Again, I agree O/R can be really usefull, but it can also be really overkill. If you start with a good working knowledge or O/R it's quite logical to use O/R. But if you're an expert in SQL, why throw that knowledge away? objectA.objectB.usersList.user[1].name This is great to use this kind of Objects inside JXTG or in other places. Once you start using it, you will see there is not way back to plain SQL. And who on earth needs a bridge or relational mapping for Select username, password from authentication where username = 'foo';? If you already have OJB up and running it is logical to use that, but to start learning OJB just for that??? I wonder if when SQL was a top technology, people had the same arguments as you against SQL. Yes, of course. No-one likes to revalue his knowledge like Enron shares. And it was valid then, less valid now. Like SQL vs O/R nowadays. SQL has a lot of existing knowledge and tools. O/R is only starting. Books and tools about/for OJB are more difficult to find than for SQL. Which makes the technology harder to use - even if it is both better, less error prone and faster. And 15 years from now I will probably just as hard say that we should not go to a situation where the database uses both voice recognition andsemantic analysis on a recording or your voice to determine what you want from it, and give you the results spoken on your cellular phone:)
Re: Modular database component
Ugo Cei wrote: Leon Widdershoven wrote: I honestly do not care about the efficiency of my SQL. The database is by far the fastest component. I do not think OJB can really optimize a simple SELECT foo, bar from BLA; statement. There's just nothing to optimize! You can always optimize it away. That is, don't do the query at all if you have cached the data. Since any serious ORM solution will give you declarative and transparent support for caching, this alone is a big win in some situations, IMHO. Ugo I stand corrected. Leon
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Guido Casper wrote: Leon Widdershoven wrote: Guido Casper wrote: Yes that might be one reason. Another one IMO is that it's much easier to (conceptually) come up with a reusable sitemap component (being a specialized thing) than it is to come up with a reusable flow component. Guido I think that is the true question. I am writing an application which gets an excel spreadsheet with information; this information must be read into data structures, and compared with existing databaserecords, and then merged. I use flow to get the user data. I have tried to write the total application entirely in Javascript (with of course HSSF Java classes). It works, but is not really maintable. So I wrote a reusable flow component called a Java Package. The main class gets the uploaded spreadsheet and all flags, and returns errors or OK. It can be called from any flowscript program, the classes can be configured, it can be called by Java classes. How much more reusable can you get? And at the same time I think this is not what flowscript developers call reusable. What is the characteristic of a reusable flowscript component, defined in a way a user can understand? For cocoon components that's easy. Implement a particular interface and it is a particular kind of component. But flowscript is just much more free on the one side, and in other ways a bit more restricted. But it is possible :-), like somewhat being proved by CForms (and other components as well but CForms is the only one with a dedicated flowscript API). I'm quite excited about the recent discussions about the best database interaction layer. It may result in several approaches in parallel (which is perfect as there are quite various requirements being targeted by db apps/tools) but I feel one (or several) of those might evolve into something like a prototype of a reusable flow component (or be the base of another layer providing the prototype of a reusable flow component :-). Guido Me too. I do hope that more than one way of doing things will be created. There is nothing like darwinism to determine what is really usefull. Besides, the Object/Relational mapping can also be done in (at least) two ways. I even saw a listing of about 9 Java O/R frameworks! Some free, some not. I think Hibernate and OJB are the most probable early adopters, though OJB withJDO has a bit of a disadvantage since the required libraries cannot -apparently - be bundled with cocoon but must be downloaded by sun, which is a bit of a set-back concerning the samples block. I however do look forward to an O/R framework with javascript, besides a simple SQL engine, of course. I have started playing with O/R myself as I found it both easier to understand (a single framework is an advantage), and found better understandable documentation on it. It helped that my reverse-db of OJB tool did not work out of the box (as a typical user who earns his meager(:) bread with development I do like non-core (for me) functionality to work out of the box). Leon
OT: [RT] Use of flowscript or the pyramid of contracts
Hi, I, as a user, do not differentiate between Components and utility classes and functions. I think that when a cocoon developer hears Component, (s)he thinks of classes which obey some sort of contract by implementing an interface. If I, as a user, think of a component it is a part that does something and is easily integrated into the flowscript. And example for Javascript flowscript is of course woody.js. This integrates fabulously with flowscript. Unfortunately, the same does not hold for database actions. As I user, I could not find a way to access databases without just using the classes from java.sql, though I did manage to get a Connection from the pool from the manager. As a *hacker* I used parts of the samples plock (PetStore); the sample block contains an excellent module, part of the petstore, to access databases and represent resultsets. And what I'm wondering is why such a usefull component for an example is part of -of all things - an example block in stead of an optional JavaScript/Database block. I have the feeling that people might be more willing to make components for flowscript (and the same would probably hold for other flow languages) if components did not look so application specific. I use Dababase.js; but the sources are part of the samples, so I for one have the feeling it is a totally unsupported module. In short, I think existing components could be more clearly presented as components for re-use. I have the feeling there are quite a lot of usefull components 'out there', but it's hard to get a list of the available modules for flowscript. In contrast, it's quite easy to get such a list for xsp, which is why a lot of people just use xsp even when flowscript would be better suited. That was my optinion. I do not own asbestos underware but I *can* duck. Leon
Re: OT: [RT] Use of flowscript or the pyramid of contracts
To me, hibernate is overkill and yet another thing to manage. The advantage of esql is that it is simple, and has a single layer access to the database. Hibernate is more complicated to set up, and then has to be maintained. If you use plain SQL, only the queries have to be maintained. If you use hibernate, it also has to be maintained. For plain old statements like select * from foo where bla=xsp:request.../ it's just overkill to me. I do think hibernate is very good - for advanced usage. I think it is a shame that people are forced to either use xsp or use plain java.sql access to the database in flowscript. the combination Javascript and SQL is hard enough for beginners - starting out with yet another component that needs to be configured is IMHO just too much. Please note that I do not undervalue Hibernate, or OJB. But they are both powerfull tools, and powerfull tools tend to be harder to initialize that simple stuff (sql) for simple work. That this is not suppurted is the reason that I only use flowscript where I really need a multi-stage flow. XSP is still better suited (easier to read, modify and maintain, debug) for simple SQL queries and updates. A shame as flowscript is more powerfull and better suited to development. Leon Antonio Gallardo wrote: Leszek Gawron dijo: On Mon, Apr 19, 2004 at 09:01:28AM +0200, Leon Widdershoven wrote: Hi, I, as a user, do not differentiate between Components and utility classes and functions. I think that when a cocoon developer hears Component, (s)he thinks of classes which obey some sort of contract by implementing an interface. If I, as a user, think of a component it is a part that does something and is easily integrated into the flowscript. And example for Javascript flowscript is of course woody.js. This integrates fabulously with flowscript. Unfortunately, the same does not hold for database actions. As I user, I could not find a way to access databases without just using the classes from java.sql, though I did manage to get a Connection from the pool from the manager. As a *hacker* I used parts of the samples plock (PetStore); the sample block contains an excellent module, part of the petstore, to access databases and represent resultsets. And what I'm wondering is why such a usefull component for an example is part of -of all things - an example block in stead of an optional JavaScript/Database block. I have the feeling that people might be more willing to make components for flowscript (and the same would probably hold for other flow languages) if components did not look so application specific. I use Dababase.js; but the sources are part of the samples, so I for one have the feeling it is a totally unsupported module. because it is a totally unsupported module. Long time ago it was considered a bad practice to call actions from flow so the new FOM does not have it. It results in the fact that you are not able to use ESQL if you use a flow application. ESQL is lost and you do not have any substitute (the database.js you mention is considered a prototype only). And though all developers say : use O/R tools I started from simple xsps because cocoon itself was to much for me to handle at once. After some prototypes I switched to Hibernate and would never go back to ESQL. Not using Hibernate. I use OJB. And I agree that there is no way to go back. but still I recommend to all my friends to start simple with esql. You are cruel! :-D We are trying to show people the right things from the beginning: Last week, we training our new coworker with PHP background. We started to show the Cocoon world with OJB+JXTG+CForms+Flow. After 2 days of intensive training (8 hours each day and BTW, I cannot speak anymore) + Carlos the day after guiding in a sample of a contact DB webapp (cca. 5 tables) in 1 day. Our coworker, realized how good Cocoon is and the nice approach. I hope to see the progress this week. while start working real life projects. I am aware there are even more things to improve in our development approach, but the current archievement show us we are going in the right path. As I have written in some previous post: with flowscript you gain a lot of freedom and make development much simpler but because of lack of database abstraction language you have to use components with pure JDBC which makes it a lot harder in the business layer! Looking for SQL support in javascript? ... What about Groovy: http://groovy.codehaus.org/sql.html Best Regards, Antonio Gallardo
Re: OT: [RT] Use of flowscript or the pyramid of contracts
I had a task to write a web interface to a table with 300 columns. The column names were still in flux. I really did not feel to write 300 elaborate column definitions. XML is very readable, but it was too verbose for me at the time. And as you say, it looks a very daunting task and that's what most starting users probably think. And if they, because of that, start with xsp and esql (which admittedly is very easy) the going forth to yet another language and framework can be inconvenient. Especially when you get paid to write applications, not learn frameworks:) But I'm glad to hear that Hibernate is quite easy to start with. The moment I get some time off I will certainly jump in the deep and try to survive:) Leon Leszek Gawron wrote: On Mon, Apr 19, 2004 at 12:32:38PM +0200, Leon Widdershoven wrote: To me, hibernate is overkill and yet another thing to manage. The advantage of esql is that it is simple, and has a single layer access to the database. Hibernate is more complicated to set up, and then has to be maintained. If you use plain SQL, only the queries have to be maintained. If you use hibernate, it also has to be maintained. For plain old statements like select * from foo where bla=xsp:request.../ it's just overkill to me. I do think hibernate is very good - for advanced usage. I think it is a shame that people are forced to either use xsp or use plain java.sql access to the database in flowscript. You are not right. Setting up hibernate and writing first application consisting of 5 tables took me 1 hour. For two weeks I been gathering strength to do that because I've been as scared as you are :) lg
Re: OT: [RT] Use of flowscript or the pyramid of contracts
Leszek Gawron wrote: On Mon, Apr 19, 2004 at 03:24:50PM +0200, Ugo Cei wrote: Leon Widdershoven wrote: But I'm glad to hear that Hibernate is quite easy to start with. The moment I get some time off I will certainly jump in the deep and try to survive:) There is a middle ground between a full-fledged O/R mapping layer and raw JDBC calls. You could, for instance, try Spring's JDBC template classes [1], as they take care of the tedious, repetitive and error-prone, like setting up a connection, managing transactions, handling errors and properly releasing resources. An advantage of using Spring is also that it supports Hibernate and JDO out-of-the-box, so graduating from JDBC to an O/R persistence layer might be easier. DISCLAIMER: I've never used Spring, just read its documentation and I really like what I've seen so far. Might be using it for a future project, though. Ugo http://www.springframework.org/docs/reference/jdbc.html There is also a library called DbUtils at Jakarta (http://jakarta.apache.org/commons/dbutils/). DISCLAIMER: I've never used DbUtils, just read its documentation :) quote: DbUtils is a small set of classes designed to make working with JDBC easier. JDBC resource cleanup code is mundane, error prone work so these classes abstract out all of the cleanup tasks from your code leaving you with what you really wanted to do with JDBC in the first place: query and update data. lg I also read the docs for that. As it happens I already had a home grown mini library to do just that before I saw this. There are quite a lot Java packages that work more comfortable if you just wrap them in some exception-catching auto-initialisation classes:) The original topic was, though, that there is no easy default for database access within flowscript. And I think a light and advanced recommended way for database access from within flowscript would do a lot of good. This is, though, not going to happen if I've followed the discussion right:) Leon
Re: OT: [RT] Use of flowscript or the pyramid of contracts
Just curious (also:), how much work is it to set up for a given database? Leon leo leonid wrote: Hi all, just curious, did ever someone in cocoonland, except me, use the SQL-Maps and DAO-Framework from ibatis ( www.ibatis.com ). This is from where Chris borrowed the Petstore sample, that he ported to flow. And that was the simple reason why I hit upon these tools, that I use since, contently. I never tried something similar before and since, so I can't rate it, or even compare it, with the tools you use (Hibernate OJB,..) so, comments would be very appreciated. For training with these tools, I half backported the petstore flow sample, so that it uses flow only for controller things, but leaving all business logic under the responsibility of SQL-Maps/DAO. If there is an interest, I could finish and contribute this alternative petstore sample. /leo On Apr 19, 2004, at 1:54 PM, Leon Widdershoven wrote: I had a task to write a web interface to a table with 300 columns. The column names were still in flux. I really did not feel to write 300 elaborate column definitions. XML is very readable, but it was too verbose for me at the time. And as you say, it looks a very daunting task and that's what most starting users probably think. And if they, because of that, start with xsp and esql (which admittedly is very easy) the going forth to yet another language and framework can be inconvenient. Especially when you get paid to write applications, not learn frameworks:) But I'm glad to hear that Hibernate is quite easy to start with. The moment I get some time off I will certainly jump in the deep and try to survive:) Leon Leszek Gawron wrote: On Mon, Apr 19, 2004 at 12:32:38PM +0200, Leon Widdershoven wrote: To me, hibernate is overkill and yet another thing to manage. The advantage of esql is that it is simple, and has a single layer access to the database. Hibernate is more complicated to set up, and then has to be maintained. If you use plain SQL, only the queries have to be maintained. If you use hibernate, it also has to be maintained. For plain old statements like select * from foo where bla=xsp:request.../ it's just overkill to me. I do think hibernate is very good - for advanced usage. I think it is a shame that people are forced to either use xsp or use plain java.sql access to the database in flowscript. You are not right. Setting up hibernate and writing first application consisting of 5 tables took me 1 hour. For two weeks I been gathering strength to do that because I've been as scared as you are :) lg
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Guido Casper wrote: Yes that might be one reason. Another one IMO is that it's much easier to (conceptually) come up with a reusable sitemap component (being a specialized thing) than it is to come up with a reusable flow component. Guido I think that is the true question. I am writing an application which gets an excel spreadsheet with information; this information must be read into data structures, and compared with existing databaserecords, and then merged. I use flow to get the user data. I have tried to write the total application entirely in Javascript (with of course HSSF Java classes). It works, but is not really maintable. So I wrote a reusable flow component called a Java Package. The main class gets the uploaded spreadsheet and all flags, and returns errors or OK. It can be called from any flowscript program, the classes can be configured, it can be called by Java classes. How much more reusable can you get? And at the same time I think this is not what flowscript developers call reusable. What is the characteristic of a reusable flowscript component, defined in a way a user can understand? For cocoon components that's easy. Implement a particular interface and it is a particular kind of component. But flowscript is just much more free on the one side, and in other ways a bit more restricted. I think you could slowly move towards enforcing a FOM only access to Cocoon; maybe start with two levels of access: a default FOM only and a RAD flag (developer_mode='true') that be configured to say to Cocoon that a developer wants to allow script X to have access outside of the FOM model ? No, please no. It is hard enough to find components/scripts that do what you want them to do - without reinventing the wheel. It really is not a good idea to artificially limit access to ready-made logic and thus forcing users to either hack the cocoon sources, or to reinvent the wheel. What you can say is that particular scripts should be considered private or protected to indicate that their contract may change at any time without notice and that it is thus very unwise to build a system based on that. (Yes, like Java). A protected script also makes sense if it manages a resource which must be called only when particular demands have been met, or which may have side effects on the fllowscript environment. But both such cases would be to protect the user, and not to force users to a certain development model favoured by the developer. The developer may well be right in his opinions, but users come from different backgrounds and would not understand they be limited because their way is not neat. I am sorry if this sounds to harsh, but it really *is* hard enough to find functions which do what you want them to do. If you then find out those functions are blocked for some unfathomable (ideologic) reason, you would not be glad. If I read to much in the statement above I am sorry. But I strongly feel that flow is a more powerfull technology than xsp for many applications, and that it should be kept simple for users. And simple is not a limited set of functions, but a feature rich environment which allows you to do what you want without to much Java (a bit like xsp is now), Leon
Re: #{//foo/bar} doesn't work within forEach!
Could it be that you are using both Jexl and XPath tags?
Stephan Coboos wrote:
Hello,
I've tried to retrieve an object within a JXTemplate:
#{//foo/bar}
This works fine outside any forEach. If I'am using it inner forEach,
nothing will be printed out:
jx:forEach var=something items=${myList}
#{//foo/bar}
/jx:forEach
Because // refers to the root, the value should be printed out within
this context, right? Whats wrong?
Thank you.
Regards
Stephan
Re: [RT] Checked exceptions considered harmful
Bertrand Delacretaz wrote:
Le 14 avr. 04, à 20:00, Leon Widdershoven a écrit :
...I don't think throws Exception in all declarations is a plus; a
function which operates on files could have an IOException, a function
which operates on numbers a NumberException
or something akin; in essence, the root of the expected Exception
hierarchy (for interfaces and abstratc classes)
I like the idea, similar to what Berin suggests: using base exceptions
which tell us what the problem is about, without being too specific.
-Bertrand
Similar but *not* the same. And it holds only for interfaces. I think the
actual classes should be a bit more specific (not just Exception - that
doesn't tell anything).
But to give an example, I define a virtual DataSource (not a cocoon/avalon one):
interface DataSource {
// ...
public String getData() throws IOException;
}
In does not matter why a datasource could not get the data. Whether
a file is not found, could not be read, a netwerk address is not available,
a database does not exist, an SQLException occurred - for this function
it only matters that no input could be obtained.
An implementation should then of course re-wrap the exception to an IO
exception. With an appropriate message (I think cocoon has good exception
messages btw).
I think it is important in such a case to be generic since it is extremely
hard for software to automatically correct any problem in such a case.
You might want to access a backup data source, but for that you only need to
know that the operation has failed. Not exactly why (it should be in the
logs though). If you/the software knew a file does not exist, could it
automatically create one with the requested data? Normally not - if you
had the data you would not need to ask it.
That is why I think overly specific exceptions are not always the best
way - the exceptions you specify as a library developer should not just
image the exceptions thrown by used functions, but be of use to the calling
developer. And (s)he want's to know whether the action has failed.
Leon
Re: GroovyMarkup syntax works!
You don't have access to a ServiceManager or ComponentManager (provided by cocoon and holding the configured pools)? Bertrand Delacretaz wrote: Le 15 avr. 04, à 18:20, [EMAIL PROTECTED] a écrit : ...You might as well just use DataSource then as this is pretty close to all DataSource is. (Or at the least get ConnectionProvider to implement DataSource) There's an implementation in Jakarta Commons dbcp and various JDBC drivers come with an implementation of DataSource for you already (e.g. Oracle Axion). If nothing else just provide a DataSource facade to whatever connection pool you use and the groovy.sql.Sql will work fine with your pool. Sounds good, I'll try it! -Bertrand
Re: GroovyMarkup syntax works!
of course, I'm working on a static factory class for myself which does only that:) Bertrand Delacretaz wrote: Le 15 avr. 04, à 19:37, Leon Widdershoven a écrit : You don't have access to a ServiceManager or ComponentManager (provided by cocoon and holding the configured pools)? Sure - it just needs a little bridge to make the pools or Connections available to the scripts. -Bertrand
Re: [RT] Checked exceptions considered harmful
Leo Sutic wrote:
meaning: when cleaning out stuff, you shouldn't throw out the real
valuable parts (even if those were the cause that got you in the mess)
I think you end up with something like:
+ If the thing you are signalling via an Exception could be made
into a error return value that the client code *really should
check for* as opposed to *can check for*, then make it a checked
Exception. This ensures that the client code will check for it.
+ If what you are returning is guaranteed to be unrecoverable and
stop any processing, throw an Error.
+ Else make it a RuntimeException.
The whole point with checked Exceptions was to avoid the case when
lazy programmers didn't properly check for ok return codes.
/LS
In stead you are forced to spend 80% of your code handling exceptions. I
think the thought is
that if you spend all that time write try{}catch(){}finally{} clauses
you also write someting
in that catch(generally a throw unfortunately, and often a more generic
one since you don't
waht to throw 3 different exceptions just because you can't (1)Open a
file for (2) Reading
because the (3)file can not be found. (Did I forget something?)
BTW, I like exceptions - in general - but Java (especially the standard
libs) make so much use
of them that the effect is more like Oh no - another one in stead of
Oh yeah - that can happen.
Leon
Re: [RT] Checked exceptions considered harmful
Berin Loritsch wrote: Leo Sutic wrote: From: news [mailto:[EMAIL PROTECTED] On Behalf Of Berin Loritsch Really? I did the exact same thing and got an error during compilation. It must be a stricter IDE specific compiler. I'm not sure that we can count on that continuing to be the case forever though. No, but they have to change the Java language spec for it to happen: http://java.sun.com/docs/books/jls/second_edition/html/exceptions.doc.ht ml The runtime exception classes (RuntimeException and its subclasses) are exempted from compile-time checking Ok. You learn something new every day. So then the compiler that forced me to check those exceptions was overzealous or in violation of the Java spec. Exempted -as far as my english goes - is excused. If you are exempted from class you need not go to that class, but if you wanted to you could. (It's been a long that, school, maybe I got that wrong:) Does exempted mean compiler is not allowed toor compiler does not have to (the latter would be evil of course since it would leave a degree of freedom in the specs, but I don't think that's exacltly unheard of) Leon
Re: [RT] Checked exceptions considered harmful
Bertrand Delacretaz wrote: Le 13 avr. 04, à 21:54, Ugo Cei a écrit : The subject of this RT is the issue of checked vs. unchecked exceptions and the horrible things the abuse of checked exceptions does to our code base... Agreed - and I've read some of the stuff you mention, but I have a slightly different point of view: I tend to declare throws Exception everywhere (or at least in interface declarations), as using unchecked exceptions only can be very confusing to programmers sometimes. Using the throws clause makes it clear that you expect something to eventually happen. I don't think throws Exception in all declarations is a plus; a function which operates on files could have an IOException, a function which operates on numbers a NumberException or something akin; in essence, the root of the expected Exception hierarchy (for interfaces and abstratc classes). An illegalArgumentException and NullPointerException need not be declared (and are not declared) since they form part of the Contract. You can (and should IMHO) declare as many demands as possible *and* convenient for the user (things that are easily checked) in the contract. If you end up with dozens of exceptions in one function, all possible due to wrong arguments (or combinations thereof) I think even the interface could use a function_doesNotCheck() throws FewExceptions and function_doesChecks() throws zillions of expetions. This preference has to do with the way I read interfaces. If I see a throws exception, I just let the code die or do a catch all in the hope it will survive. If I see something concrete, I know what can happen and I might know a recovery technique. This of course has the disadvantage that implementing an interface at a later time can be a pain since the newly found exceptions are officially not thrown, and thus need a hack to propagate (a rewrap or something alike). I think that is very much a matter of taste. I must admit I have a background in C++, so I perceive exceptions more like errors that as control flow, which probably colours my arguments:( Leon
Re: To make XML on the fly
try localhost:8080/cocoon/samples/linkrewriter/bookdemo/ and pay attention to the headings (index, overview, installing/index) It could also be that yuo want to imitate the Cocoon wiki pages: your trail on top of the screen. I don't know how that is done, but if that's what you want there *are* people who know how to do that:) Leon Elvira Nieto Carretero wrote: Hi I have in mind is fairly close to your last proposal. Exactly i want to save the path of links that the user of my site web do and i want to insert a new xml label in my navigation.xml once the user to click over a link of my menu. do you understand me? Thanks again. Best regards - Original Message - From: Antonio Gallardo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, April 14, 2004 11:11 AM Subject: Re: To make XML on the fly Elvira Nieto Carretero dijo: Hello again If a pipeline basic is compose by map:pipeline map:match pattern=* map:generate src=my_xml.xml/ map:transform src=my_xsl.xsl/ map:serialize type=html/ /map:match how can i to apply a transform (my_xsl.xsl) to xml on the fly? Hi: Can you elaborate more what you have in mind? Because, AFAIK, all the cocoon tranformations are on the fly. :-D That is, can i make a xml structure in memory and then to apply it a last transformer my_xsl.xsl? The generator job is to emit SAX events that are consumed by a transformer. The tranformer can be of the default type XSLT. In this way, it can be interpreted as done in memory or on the fly. And this is what Cocoon is all about. Another answer to the question can be: You can also point to another pipeline to generate the XML source. In that way it is called a dynamic generated XML file. Is that what you have in mind? If so, see for the cocoon: protocol: http://wiki.cocoondev.org/Wiki.jsp?page=CocoonProtocolExample Best Regards, Antonio Gallardo
Re: Back button of my navigator
I'm no wizard but I think the problem is that browsers cache the page. The browser should request the page again when Back is pressed. There is a HTTP1.1 header no-cache which should be set on the page. I don't really know how to do that - something like response.setHeader( Cache-Control, no-cache); response.setHeader(Pragma, no-cache ); a no-store, or must-revalidate header could also be an option but I'm not at home with those headers. If there's a wizard around to (s)he might tell you how to set those headers in the sitemap, xsp or flowscript (I don't know what you use - but the sitemap is a good option I think; maybe a configuarion of the html serializer?) Hope this is at least a pointer in the right direction, leon Elvira Nieto Carretero wrote: I use session variable to save the links navigation that the user press during his permanence in my web site. But, if the user press the back button of the navigator, my session don't update and the next link that he press appear the step that it had to undo when back button of the navigator was pressed. do you understand me?... i hope yes. best desires
Re: Back button of my navigator
First of all, caching should be implemented by the client (browser). If that does not listen to the cache directive, you are out of luck. Cache-Control is implemented by all http1.1 conform clients (otherwise it's not conform:). I think every modern browser is such a client (IE6, Mozilla, Opera, Konqueror...).. Older browsers often, but bot always, use Pragma. That's I think in Netscape 4.x and such. If you need compatibilty with very old browsers you have to look up their docs. Cache-Control also protects you from eager proxies, which can also cache data. And so does Pragma:) Cache-Control is also good for secret, or sensitive data, but i think private is the more correct directive for that (it tells proxies not to cache). For a news site which is updated once an hour you can add an expiration date. That's what I know. I don't usually have a lot to do with that stuff. If you have special needs just look up the http1 and http1.1 specs. Headers can be usefull. Leon [EMAIL PROTECTED] wrote: hi leo let me ask you something: just adding this action in a map:match and set the parameter Cache-control to no-cache can you know serve pages that are not cached from client? or is somenthing more that i'm missing? thnx --stavros On Tue, 13 Apr 2004, Elvira Nieto Carretero wrote: Hey, Leo E U R E K A ! Rulez! In my country it say Eres un solete, in english it would be something so you are a sun ;P Best desires - Original Message - From: Leon Widdershoven [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 13, 2004 5:14 PM Subject: Re: Back button of my navigator Though I'm quite sure the previous information is enough (provided I got the question right), I think the following link is usefull: http://www.class.noaa.gov/cocoon/nsaa/sitemap.xmap With special attention to the set-header action and the map:act part: map:action name=set-header src=org.apache.cocoon.acting.HttpHeaderAction logger=sitemap.action.set-header/ !-- Lot's of code - see webpage -- map:match pattern=listing map:act type=set-header map:parameter name=Pragma value=expires/ map:parameter name=Expires value=0/ map:parameter name=Cache-Control value=no-cache/ map:generate type=serverpages src=docs/searchresults.xsp/ map:transform src=stylesheets/listing.xsl map:parameter name=use-request-parameters value=true/ /map:transform map:serialize type=html/ /map:act /map:match Leon Leon Widdershoven wrote: I'm no wizard but I think the problem is that browsers cache the page. The browser should request the page again when Back is pressed. There is a HTTP1.1 header no-cache which should be set on the page. I don't really know how to do that - something like response.setHeader( Cache-Control, no-cache); response.setHeader(Pragma, no-cache ); a no-store, or must-revalidate header could also be an option but I'm not at home with those headers. If there's a wizard around to (s)he might tell you how to set those headers in the sitemap, xsp or flowscript (I don't know what you use - but the sitemap is a good option I think; maybe a configuarion of the html serializer?) Hope this is at least a pointer in the right direction, leon Elvira Nieto Carretero wrote: I use session variable to save the links navigation that the user press during his permanence in my web site. But, if the user press the back button of the navigator, my session don't update and the next link that he press appear the step that it had to undo when back button of the navigator was pressed. do you understand me?... i hope yes. best desires
Woody Renamed?
Hi, I was thinking to add a bit to the WhatIsFlow (from Bertrand Delacretaz) page in the Wiki, to mention how this integrates with Woody, when I remembered I found a page some time ago that Woody had been renamed to something different. Is that true, and what is the new name? Regards, Leon Widdershoven
Re: disabling widgets
- move to a generator approach. Do you mean generator-only approach? I think that would limit the options of the users quite a bit (and I am one of those). I actually like the pipeline approach so that you can build your XML tree dynamically; if one would move to a generator only approach other generator-only functionalities (xsp, though that appears to be deprecated) can not really be used anymore. As you notice I am not well enough at home in cocoon core matters to really have an opinion, but two months ago when I started using cocoon (and I am working full time with cocoon-2.1.4) the fact that the xsp was a generator only brought me a lot of trouble so I have a bit of a phobia about that. Regards, Leon Widdershoven
xsp Serverpages generator: Convoluted functionality?
Hi, abstract I have a question about the design of the ServerPages generator, which transforms xsp pages into (at the end) a SAX stream. I think the generator wraps to distinct functions into one function, and that it could be usefull to split it into a File-like Reader into a SAX stream and a separate Transformer which transforms SAX via a compilation to another SAX stream. /abstract pre In this e-mail I address a problem which is bugging me almost from the start. I have looked at the mailing list but could not find such a thread. Whether this is because my idea is stupid or not, I do not know. I mean no critique, but i *am* curious. /pre I have noticed that the XSP generator has multiple functions wrapped into one: 1. Reading the xsp file (into a DOM tree probably) 2. Transforming this tree into Java 3. Compiling the resulting java file 4. executing this file After 4) the results is passed further in the pipeline. I have also noticed that this design results in quite some unnecessary trouble for some users, including myself. I try to use the session authentication data in my xsp pages. But that, naturally, fails since the session transformer works on the stream that results from the serverpages generator. In other words, after the xsp has been compiled. This means that values from the authentication context cannot be used; in effect it means that all logic sheets which do not bind as well to xsp as esql cannot be used to control the java control flow. I think this can be done better. It I look at the design concept of the sitemap it has generators to load data and transform it into a SAX stream, which then is processed by a transformer. The transformer takes a SAX stream, does it's thing, and returns a SAX stream, leaving intact all those tags it can not handle. At the end the serializer transforms it into the output file which may not be a DOM stream. It I try to map the ServerPages generator into that framework I notice it does two separate things: 1. It generates a SAX tree from an xsp file 2. It transforms a SAX tree into a java file, executes that file, and returns a SAX tree Though the naming is quite suggestive, I think the point is clear. I think the ServerPages generator should actually be split into two parts. That would enable other transformers to handle their tags, after which the Java control flow can take that data into account. Such a construct would allow non-xsp tags to integrate seamlessly with Java (xsp) programs. Such a separation of functionality, however, is just so natural that I really can't imagine that no-one else thought of that. So I'm actually quite curious why such a split has not been done. I'm also quite curious how the actual implementation of the generator works. I have looked at the source code of some xsp tag libraries to get other things to work, but I'm a bit scared of the serverpages generator - it just has to be complicated. I'm going to look at it anyway in the hope that internally the reading of the XML stream and the transformation into java is nicely separated, so that I can re-write it into two components. If the separation is clean, I think I can do that faster than writing my xsl's to handle session-transformed data. I don't have high hopes, however, so I would really like some comments from the people who actually wrote the generator. Regards, Leon Widdershoven
