Re: [vote] Release Cocoon 2.2-final
Grzegorz Kossakowski wrote: Dev at weitling pisze: BTW: If I could meet some of you wizards and get an indoctrination I could/would improve docs. Florian, are you coming to ApacheCon (hackathon days)? If not, I'm available in Warsaw almost all the time always willing to speak about Cocoon. :-) I'd like to, but they enchained me here, leaving me bread, water and a computer ;-) ApacheCon takes place at my first days at a new employer, I hope there will be a second CocoonGT (or the like) this year? Bye, Florian
Re: [vote] Release Cocoon 2.2-final
Sylvain Wallez wrote: Carsten Ziegeler wrote: Luca Morandini wrote: Reinhard Poetz wrote: I've prepared the artifacts for the release of Cocoon 2.2 final. There is much room for improvement in the doc though: don't you think it should be improved before release ? It would be great to have better docs, but honestly who is going to write them? We can either release with the docs we have or wait forever for better docs and never release. From these two choices I prefer the first one. Anything between these two extremes is imho not going to happen. We might not get some new users because of bad docs, but we might get people really interested in a new Cocoon. If we wait for better docs we loose everyone as we never release. Yup. And add to this the fact that doc lifecycle is different from the software lifecycle, since there is no doc releases, but a continuous improvement. Sorry, I can't agree. Cocoon still has the same fault as many open-source products: A lack of documentation. I don't know if GSoC is for docs, too, but it is really, really necessary to improve docs. It's still the same Catch-22: To write docs you need to understand the developed, to understand the developed you need the docs, ... Writing docs does belong to development, even when it seems to be at a kindergarden level for newbies! Just my 0,02 CHF Florian
Re: [vote] Release Cocoon 2.2-final
Carsten Ziegeler wrote: Dev at weitling wrote: Sorry, I can't agree. Cocoon still has the same fault as many open-source products: A lack of documentation. I don't know if GSoC is for docs, too, but it is really, really necessary to improve docs. It's still the same Catch-22: To write docs you need to understand the developed, to understand the developed you need the docs, ... Writing docs does belong to development, even when it seems to be at a kindergarden level for newbies! I think we all agree that we need docs (or more/better docs), absolutely no doubt. And I think we also agree that writing docs is one task of the development process, and it's an important task. But we can't force anyone to write docs; and delaying a release because of lacking documentation is not producing the desired effect: instead of getting docs this way, nothing is usually happening: no docs and no release. I don't say that I'm happy about this. Despite my sometimes dumb question here on the list I know Cocoon is really cool and still improving. But without good docs the developers and the users separate more and more. There are many people who want to contribute to Cocoon, but most of them do only have spare time and are not paid by a company with interest in Cocoon. For them it's really hard to dig trough the docs to understand things before they can even think of contributing code. Why not introduce documentation releases? BTW: If I could meet some of you wizards and get an indoctrination I could/would improve docs. Florian
Re: JNet integration
Carsten Ziegeler wrote: Joerg Heinicke wrote: That's why I wonder where a pipeline writer gets into uri resolving at all? Why does he have to care about URLs or Sources? That's the component developer's concern. The pipeline writer needs to know how uri resolving works. Still: Why? He needs to know what input values are allowed, what relative values mean etc. Have to think about this part. Regards, Florian
Re: Layered software designs
Reinhard Poetz wrote: Carsten Ziegeler wrote: The question is now if we need support for caching in the low level apis or if it is possible to have a layered approach - which would make the entry barrier much easier. Yes, this layered approach is what I'm aiming for. All the reactions in this thread make me think that everybody, who has commented on this mailing list so far (except Carsten), believes that we want to throw away good things that have profed to be useful in many situations. Rest assured, that's not the case. Carsten and I only want to break up this all-or-nothing situation that we (still) have now. What I want to see is a concise pipeline API that comes with only little overhead in terms of its learning curve and its dependencies on third-party software. Usually this means that we stick with standard APIs as much as possible - and I think this rule applies for our situation too. This means that the user of the API only needs to learn as little as possible. When he wants more, we offer additional modules that help him. Since he has a concrete need, the motiviation to learn something new is much higher than when he has to learn everything right from the beginning. If you want to learn how this whole concept *might* apply for a next generation Cocoon, have a look at Steven's and my Exploring Corona mail from last week (http://marc.info/?l=xml-cocoon-devm=120611990603725w=2). The idea of Corona is having a concise core that doesn't have any dependencies on a particular component container (Spring, OSGi, etc.), source resolving mechanisms or environment (http, java only, etc.) or even the type of the components (XML-SAX event stream, XML-Stax event stream, binary streams, etc.) that are linked together in a pipeline. A simple scenario could be: Pipeline API + java.net.URL + XML-SAX components A more advanced scenario could consist of Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine or maybe you need the full stack that corresponds to Cocoon Core 2.2 - here you are: Pipeline API + Sourceresolve + HTTP-enabled + Sitemap Engine + Spring XML-SAX componnents This layered approach makes Cocoon easily embeddable in any Java application and Cocoon's learning curve becomes more gradual. Is such a situation only appealing to Carsten, Steven and me? Your mail makes things a little bit more clear. But (maybe I have missed some mails) how do you want to make this Pipeline API? E.g. a SAX-based pipeline is something different than image data running through several filters. How do you want to prevent the use of a SAX-events generating component together with an image data transformer? What about something like it's used in clipboards: each component offers a list of importable and exportable formats? Just my 2 Räppli :-) Florian
Re: Layered software designs
Reinhard Poetz wrote: Dev at weitling wrote: But (maybe I have missed some mails) how do you want to make this Pipeline API? E.g. a SAX-based pipeline is something different than image data running through several filters. How do you want to prevent the use of a SAX-events generating component together with an image data transformer? What about something like it's used in clipboards: each component offers a list of importable and exportable formats? See http://marc.info/?l=xml-cocoon-devm=120611990603725w=2 Do the explanations that this mail answer your question? Quote from the text: We hope that this gives you enough hints in order to understand Corona. We are very interested in further discussions. So fire at will! My Answer: Great work! And yes, it answered my questions :-)
Re: [GSoC_2008] Project ideas
Vadim Gritsenko wrote: I'd change the order a bit. First I'd suggest to make sure (and fix if necessary) existing samples. Once this is done, the block should be released. After that, you could start (as necessary) avalon to spring migration, and development of new samples. Concerning the samples: It would be a great improvement to have the related code visible with the sample in browser. It's annoying when you have to manually grep whole directories for the appropriate sitemap or flowscript with a url as only information. Florian
Re: C2.2 dojotoolkit
Hi Sylvain, thanks for answering. Sylvain Wallez wrote: Prototype/Scriptaculous has a smaller scope than Dojo that brings loads of features. You don't have to use all of them though and can strip down Dojo with the compressor they provides that embeds and obfuscates everything you need in one file. Prototype also considers that it owns the page and tweaks the prototype of many built-in classes such as Object, Array, Element, etc. This makes code more compact but has the very important drawback of breaking other libraries you would like to use in the same page (particularly the for (prop in object) construct no more works as expected). Yes, recently I've seen that, too, using Scriptaculous in a current PHP project. Seems rather invasive. As far as documentation is concerned, I have no opinion, digging in the code more often than reading the documentation :-P Thank god docs of Dojo have improved, the only book I could find is cheap but rather thin (Dojo Toolkit. schnell+kompakt by Michael Seemann). That being said, upgrading to Dojo 1.x is definitely something to be done. I personally don't have the cycles for it though... And I lack the knowledge :-/ Where do you live? So I can start a pilgrimage to convince you ;-) Regards, Florian
Re: C2.2 dojotoolkit
Hi Jeroen, if the migration to Dojo 1.0 tends to become a big piece of work what about migrating to Prototype/Scriptaculous (or similar)? I'm not the Javascript guru but it would be nice to have a feature list (including quality of documentation) for re-evaluating the client-side-javascript-library. Who was the developer introducing Dojo in Cocoon? What does he/she think about it? BTW: A list of the original introducers for the components would be nice. Regards, Florian Jeroen Reijn wrote: Hi Felix, We've spoken about upgrading at the recent Cocoon GT in Rome. We were at the point were Dojo was waiting for its 1.0 release. Now this was already a while ago and as far as I can see nobody took the deep dive into the migration yet. I know Jeremy was thinking about this, but was waiting for a project that would give him some time to actually spend on this migration. Regards, Jeroen -Original Message- From: Felix Knecht [mailto:[EMAIL PROTECTED] Sent: Monday, February 04, 2008 10:00 AM To: dev@cocoon.apache.org Subject: C2.2 dojotoolkit Hi all Trying to do some ajax stuff I did realize that we still use the dojotoolkit 0.4.3 which is a really quite old version. Are there any plans about migrating to a newer version - latest is 1.0.2 (http://dojotoolkit.org/downloads)? Regards Felix
Re: Preparing the 2.1.1 release
Grzegorz Kossakowski wrote: Quick response: I have not forgotten about this and I even have given it a look but I have a lot of personal troubles these days, current one is that I need to change a flat and it turned out I have to do this before Christmas :-( Although I am an OS programmer on my own I sometimes forget most of us are coding in our private spare time... Besides my issue I hope you find a flat that fits (sounds like a painful story?). I'm not sure when exactly I will find a new flat so I'm not sure if I manage to fix it for 2.1.11 but I promise to give a fix in any case.. Thank you and a happy new year! :-) Florian
Re: Preparing the 2.1.1 release
Hi folks, hi Grek, it would be nice to have http://issues.apache.org/jira/browse/COCOON-2126 solved (Xmas present) and included. Thanks, greetings Merry Christmas! :-) Florian Carsten Ziegeler wrote: Hi, I'm planning to release 2.1.1 in the near future. So, are the any outstanding issues? Carsten
Re: Url without extensions - how to match/rewrite
Hi Thorsten,
I'm not sure if I caught your problem completely, but what about
handling every request as html as long as there is no known extension, e.g.
map:match pattern=*.jpg...
map:match pattern=*.gif...
map:match pattern=*...
Important is that the *-matcher comes last. Or just write your own
matcher :-)
Bye,
Florian
Thorsten Scherler wrote:
Hi all,
my current client wants to navigate their website without extensions.
Meaning they want to use something like:
http://www.apache.org/dev/version-control
instead of
http://www.apache.org/dev/version-control.html
The above example is working fine thanks to the httpd servers
content-negotiation [1], but is this possible in cocoon without
implementing every single match for every single page?
I tried with the regexp matcher but could not found any pattern that
matches the documents WITHOUT extensions to then map:redirect-to
uri=cocoon://{1}.html/.
Did somebody implemented something similar or is it just not feasible
with cocoon matches?
TIA for any feedback.
salu2
[1] http://httpd.apache.org/docs/1.3/content-negotiation.html
Re: Servlet service request
Grzegorz Kossakowski wrote: Reinhard Poetz pisze: After have been using the servlet-service framework for about 1/2 a year, I have to say that I haven't been missing the access to sessions because a child-request shouldn't affect a parent request. Whatever it has to return to its parent, should be part of the response IMO instead of being passed around indirectly. I have exactly the same feelings as Reinhard on this. If you want to pass something to child request use request parameters for simple values or POST request (using postable source) for passing more complicated structures. The same goes for passing data from sub-request to parent one. Basic goal behind such design is to really, really avoid any possibility of side-effects Using sessions for passing information should be considered evil (I'm still being decontaminated and exorcised...). But what about data which is really relevant e.g. login data. Should it really passed every time? What if someone logs out? If te session is invalidated you're finished. With request still having login data you can't be sure you have left session completely. Florian
Re: lenya 2.0 release preparation - cocoon version dependency (2.1.11?)
Grzegorz Kossakowski wrote: Florian, I completely forgot about this. Since your report looks to be perfect (screenshots, sample files etc.) it should be really appreciated by fixing it. I won't make any promises but since it also affects 2.2 and there is about a month left to planned(?) release of Cocoon 2.1.11 I may have a free time to dig into it You're still my personal hero :-) Perhaps as Xmas present :-P Greetings, Florian
Re: lenya 2.0 release preparation - cocoon version dependency (2.1.11?)
Bertrand Delacretaz wrote: If Lenya is using it successfully, and if our automated tests pass (I can run them on Linux and MacOSX when the time comes) I'd be ok with making a release. There have been some small changes since 2.1.10, and little is happening in the 2.1 branch, so it might be good to do a release of that. BTW, does anyone want to adopt this orphaned issue? : https://issues.apache.org/jira/browse/COCOON-2126 Hoping against hope :-) Florian
Re: New Cocoon 2.1.10 live site: www.derecho.com
Hola Ignacio (Living fossil according to Cocoon use time ;-) it's great seeing a Cocoon site in action, but as it is completely in spanish language it's hard for most of us to have a deeper look at it. At least I see some english errors when clicking on Registrate or Entrar... Do you plan to translate or do you have some documentation? This would be great as you surely have had much work to get there! Bye, Florian Nacho (Derecho.com) wrote: Hola a todos: The past day 03/09/2007 we've put a Cocoon 2.1.10 only live site online, with big success, we all want to share our success with all of the developers of Cocoon, and give a big big thanks to all of you.. We are extensively and intensively using Flow ( thanks god we have flow :), SQL Transformer, aggregator, definitely almost anything of the Cocoon standard blocks dist, and if not using it, for sure we have plans to use it in short.. The old site was done in an ancient cocoon 1.8.2 for 1997-99, backed by a tomcat 3.3.. So we are proud to say that we are using cocoon for about 10 years now ;) The new site need some work to have all the bell and twistles working, but we think is by now a great example on wath can be done with cocoon.. Another time thanks to all, including ancient cocoon Heros ;).. And for the work, where can we found a brief description of 2.2? the build process, the new features, etc. We need to have a peek at the next cocoon version as we want to stay with cocoon for next ten years ;).. But until now didnt found any relevant infos about it.. Apart from the maillist, where the infos are a little scattered and distributed all over the days and months.. Thanks in advance.. Ignacio J. Ortega Departamento técnico http://www.derecho.com
Re: Plans on Forms block
Hi Grek, hi Jeremy, Some thoughts on my side: - Normally a Cocoon user doesn't have much contact with Dojo, iirc effects and drag'n'drop. - As a Cocoon application has to be revised switching from 2.1 to 2.2 either, Dojo changes might be checked, too. - It would be helpful if Dojo is integratable into Cocoon in a more standard way i.e. no (or at least at a minimum) differences to the standard Djo distribution as necessary. As a non-commiting reader I would be glad to see these thoughts taken into account. Bye, Florian P.S. to Grek: As there hasn't been an answer to [http://www.mail-archive.com/dev@cocoon.apache.org/msg53627.html] I still don't see the disadvantages of Ajax to prefer a fat-client over it :-? I just noticed that Jeremy Quinn would like[1] to work on migrating Forms block to Dojo 0.9 version at Hackathon. While I think it's very good idea (I don't like Ajax but we need to have something working and glittering) and would like to help as much as I can (my TODO list is already quite stuffed) I believe that we should cut final release of Forms block before migrating to Dojo 0.9. New Dojo's release brings a lot of incompatibilities that would impact our users too. Therefore I would like to see our Forms 1.0.0 release *without* Dojo 0.9. Final release of Forms would require final release of Cocoon's core so I think it's not doable to cut final release of Froms before Hackathon. Given that, I think we should tag/branch Forms before Hackathon so people are free to work on that block and focus on bringing final release of whole Cocoon afterwards. As we are close to final release of Cocoon core already I think branching/tagging one block for few weeks wouldn't hurt. WDYT? [1] http://wiki.apache.org/cocoon/GT2007Hackaton
Re: RIA technologies - which technology will win
Unfortunately, that is not true of all environments. Many large organizations such as governments and big corporations will not allow their users to install ANY plugins to their browsers for security reasons. A team of testers has to examine every piece of software installed on the network and approve it. Getting variances for a particular application is beyond most people's level of bureaucratic tolerance. And since providing their employees access to sites like Youtube is pretty low on these organizations' radar, a Flash player is not something that it is easy to get passed as an accepted piece of software unless they have purchased other software that requires it. And THAT is unlikely because developing software for large organizations that requires Flash causes this major friction point for sales. For Flash, it is a vicious circle. Given how much development is paid for by large organizations, I think it unlikely any RIA technology will become dominant unless it is embedded in something else. That means SilverLight embedded in the browser with the most market share; JavaFX embedded in the JRE since many of these organizations see Java as mission critical; or Ajax, support for which is already embedded into existing browsers. Of these, Ajax is the only technology that is currently generally available within these large organizations. Just thought I'd offer another perspective. Full ack. And some other points: - Flash is proprietary. I don't complain about the Flash isn't OS issue but it introduces dependencies we should avoid. - As with better javascript interpreters (as shall come with new Firefox) rendering time shall increase. BTW: 300 ms on client side is no problem. If it slowed down every request on server it would be... - IIRC Flash started as interpreted, too. Java is kind of interpreted. Both are (partially) precompiled. Why shouldn't javascript go the same way? - With the current Ajax/CForms solution we have a fallback option for non javascript-capable browsers and even for non HTML. Cocoon is still an XML-publishing-system so we are neither bound to HTML/browsers nor HTTP (what about the refactorings of that ServletRequest thingie?) Just my four dashes... Florian
Re: [RT] The big picture of Servlet Service Framework
Hi Grek,
you asked us to give our two cents so after a day of reading your long,
long text I'll try to ;-)
I'll surely have to re-read it but here are some thoughts:
I promised to give an overview on our Servlet Service Framework, its
status and relation to the
Resource-Oriented Architecture (ROA) and RESTful design principles.
It's my first [RT] mail so I kindly ask you to be gentle when you
appraise.
Servlet Service Fw keeps Virtual Sitemap/Pipeline Components promise
Current implementation has few limitations:
* SAX events are serialized and parsed again when making POST
request to the servlet service
* caching is not supported at any mean
* environmental data (request, session, flowscript context aka
bizData) of caller is not
available in the called service
Sounds cool, but doesn't this result in a scenario like this?:
- browser calls resource A
- resource A runs through a pipeline calling resource B
- resource A is a SAX-pipeline, serializes SAX-events to POST-parameters
for calling B
- resource B deserializes parameters, feeds its own pipeline with
SAX-events, serializes results to HTTP-like result, feeds it back to
resource B
Seems we have a loss in performance and increase in memory needs.
Attaining ROA nirvana with Cocoon
-
-- Sitemap --
It's old but still powerful component in Cocoon. As long as we deal
with URIs sitemap's matching mechanisms will be relevant. Take a look
at quotation from RWS book, When In Doubt, Make It a Resource
sub-chapter:
You probably guessed it, routes.rb file acts as simple dispatcher that
dispatches requests to the controller. Quite the same could be
achieved with our sitemap engine:
map:sitemap
map:pipeline
map:match pattern=/v1/users/*/bookmarks/*
map:call
function=bookmarksController_handle{$cocoon/request/method}
map:parameter name=username value={1}/
map:parameter name=bookmark value={2}/
/map:call
/map:match
map:match pattern=/v1/users/*
map:call
function=usersController_handle{$cocoon/request/method}
map:parameter name=username value={1}/
/map:call
/map:match
/map:pipeline
/map:sitemap
This code could be done much compact by coming up with conventions but
it's topic for another discussion, really.
I'm not sure if I fully catch on your example. Can you explain it a
little bit more (as your eMail was addresses to the users list I bet I'm
not the only one) ?
What about handling the matching of non-URIs e.g. headers?
I'm doubtful about conventions. IMO they should be only that -
conventions - and not mandatory. For example a URL visible from external
clients should not always represent the internal structure.
-- Flowscript --
When approaching ROA design we need to throw out continuations of
course. So what's the use of flowscript, then?
It's my very own opinion but I think that our controllers should be
sitemap(as dispatcher)+script(containing actual controller's code). I
think that most of us would agree that dynamic languages have some
features really useful for fast prototyping and glueing code.
I take role of flowscript and pipelines (below) really briefly because
it's quite far from big picture of Servlet Service Framework. :-)
Please explain how you want to replace continuations and flowscript. One
of the reasons why I prefer Cocoon are continuations! The extensive use
of flowscript spread on myriads of files isn't great, though, but for
controlling a flow (!) with reentrance without having to think about
restoring variables is just great.
Or do you want to move flowscript just into the sitemap?
Bye,
Florian
P.S.: What ist [RT] ? And it would increase readibility if you introduce
abbreviations the first you use them (sorry, just my egoistic view ;-)
Re: RT: map:call as generic non-redirecting controller code
Grzegorz Kossakowski wrote: Just to be sure, do you want to implement something like: map:match pattern=sth map:call function=prepareData/ map:generate src=.../ - some protocol to obtain the prepared data [...] /map:match Such construct introduces new semantics for sitemap because data returned by map:call will be available _outside_ map:call element. Now it is important what is the scope where the data will be visible. Have you thought about it already? Time for my 2 cents, sorry: To be able to put a function call anywhere in a pipeline would be great, having access to all the variables defined up till then. To return data to the pipeline for further processing via a special protocol doesn't look like the best way to go (IMO). Functions should only return (in the classical way) data to other functions calling them. Bye, Florian
Re: RT: map:call as generic non-redirecting controller code
Grzegorz Kossakowski wrote: Dev at weitling pisze: To be able to put a function call anywhere in a pipeline would be great, having access to all the variables defined up till then. To return data to the pipeline for further processing via a special protocol doesn't look like the best way to go (IMO). Functions should only return (in the classical way) data to other functions calling them. Florian, I'm not sure if I understand you correctly. What's the use to return data from function call if you can't process it later? I'm not against processing data, I want to avoid introducing a new protocol. And functions returning values the classical way (return myBestStuff;) will reduce readability of the pipeline. For few and/or small values I'd prefer variables, for many and/or big values one should think about introduce a generator or transformer weaving the data directly into the pipeline. Giving even void functions a sense: Doing something when a certain point in a pipeline is reached not directly touching data flowing through the pipe. Hope this was not even more obfuscating :-) Florian
Re: RT: map:call as generic non-redirecting controller code
Grzegorz Kossakowski wrote:
Dev at weitling pisze:
I'm not against processing data, I want to avoid introducing a new
protocol.
I think that we already have such a protocol, are you aware of
xmodule:flow-attr combo?
Not, but it looks interesting. Will have a look on it.
And functions returning values the classical way (return
myBestStuff;) will reduce readability of the pipeline. For few and/or
small values I'd prefer variables, for many and/or big values one should
think about introduce a generator or transformer weaving the data
directly into the pipeline.
By variables do you mean something like {someVar} construct in sitemap
and someVar can only contain string value?
Ok, you caught me red-handed. I still don't dream at night of the
various variable types in Cocoon. I meant a kind of business variable
cntaining Java objects.
Giving even void functions a sense: Doing something when a certain point
in a pipeline is reached not directly touching data flowing through the
pipe.
That's what I would be against to. Side effects is the last thing we
need in pipelines, IMHO. Personally I would like to see possibility to
call function only at the *beginning* of the pipeline and *before*
data is even processed. Exactly the same way actions are called today.
The point about implementing generator is valid only if you want to
implement something generic enough to call it component (generators
are components). Implementing use-it-once components is anti-pattern,
IMHO.
Yes, of course, implementing a use-it-once component is anti-pattern.
What about this:
map:call function=sayHelloToAuntBerta/
map:generate type=kissPrepare/
map:call function=sayNo/
map:transform type=kissApply/
map:serialize type=chubbyFacePincher/
map:call function=makeNoteNeverToTantalizeLittleChildrenWhenGrownUp/
... where the functions just print something to a file, let the computer
make weird noises, whatever, but NOT process those big humid kisses...
The concept of pipelines is creating sax event, modifying and
serializing sax events. Extensive use of functions injecting data would
open a new parallel kind of pipeline.
As Ellis Pritchard pointed out in his first post: It's about control
flow not processing data.
BTW: Will Actions be replaced by something more readable in future or
did I miss the discussion about?
Florian
Presumed bug in Dojo/Cocoon integration
Hi, (this is a repost of a mail to the users mailing list) messing around with some presumed bugs in my application for the last week I finally think the bug is in the Dojo/Ajax/(X)HTML integration in Cocoon 2.1.10. The problem: If I use Ajax in my Form and serialize it as html then on action (pressing the Add answer- or trash-button) the table layout becomes very ugly. If I serialize to xhtml it looks perfect but every action performs a full page reload because Ajax doesn't work. I would be glad if anyone could have a look on my app (you'll find it along with the screenshots at www.weitling.net/Zip4Cocooners.zip) and confirm this behaviour. Correcting the bug in Dojo/Cocoon/whatever would be even greater :-) Greetings, Florian
Explanation of the Cocoon directory structure
Hi! The Cocoon directory structure isn't very concise: many directories with the same or at least similar names at different locations, some directories with non-intuitive names (e.g. lib/endorsed: why endorsed?). If there's a problem I don't know where to look, I don't know where to place my files, I don't know which parts are superfluous and and and... Are docs about that anywhere in the outside world without having to pay $ 30 for an outdated book? Bye, Florian
[WEBSITE] 2.1/installing/jars.html
This page returns an autogenerated message asking me to inform you. Its wish is my order ;-) And: On the left side there's the point Updating to version 2.1.5. May it be outdated or was that a difficult change? Greetings, Florian
