Re: WildcardMatcherHelper caching issue
On Sat, 2007-01-06 at 01:03 +0100, Alfred Nathaniel wrote:
On Fri, 2007-01-05 at 13:45 +0100, Bruno Dumon wrote:
Hi,
I noticed the new WildcardMatcherHelper class holds an internal static
map for caching. In the older solution, it was up to the caller to cache
the compiled pattern (similar to how regexp libraries work). This had
the advantage that the caller itself can decide whether the pattern
should be cached. It also avoids a potential memory leak if this code is
used to evaluate always-changing patterns, and avoids the need to do
hashmap lookups.
So I'm wondering if anyone would mind if I change it back so that caller
caches the pattern?
Thanks for any input.
The integrated cache is a convenience for the many client who repeated
match the same pattern and gain performance without having to code their
own cache management.
If you have an application where you will be matching a lot of one-shot
patterns, you could add
public static Map match(String pat, String str, Map cache)
which can be called with a null Map to by-pass caching. The old
signature then becomes simply
public static Map match(String pat, String str) {
return match(pat, str, cache);
}
The built-in cache could also use a WeakHashMap to avoid ever-increasing
memory consumption.
Thanks for the info.
I don't actually have an immediate use for one-shot patterns, however
I'm using the wildcard matcher and noticed the change. I thought the
compiled patterns were usually just kept in instance variables, hardly
deserving to be called cache management, though I must admit I didn't
study how it is done everywhere. Having this cache inside the
WildcardMatcherHelper seemed like a step back to me. But if needed
non-caching behaviour can indeed be added later again while keeping the
convenience of the default cache.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Current status of the new documentation
On 6 Jan 2007, at 20:22, hepabolu wrote: Jeremy Quinn said the following on 6/1/07 20:22: OK, I only have 'guest' under the role menu, so I assume someone has to enable me as a doc-editor? Fixed. Your default role is doc-editor, but I've also given you the doc-committer role (since you're a committer ;-) ) which is allowed to put documents live. Thanks Helma ( oh ! now I have to do something :-) ) regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: [continuum] BUILD FAILURE: Forms Block Implementation
Joerg Heinicke wrote:
Was this failure in any way caused by my commit?
No
The test case classes
seem to miss everything. What can cause such failures?
see http://marc.theaimsgroup.com/?t=11678551841r=1w=2n=3
Did my commit
(like any other commit would have done it) trigger anything special?
Continuum only rebuilds a project, if something has changed in SVN.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: blocks-fw samples etc. (was Re: What is the deal with blocks)
Mark Lundquist wrote:
On Dec 28, 2006, at 10:00 AM, Reinhard Poetz wrote:
Also: how do I run the sample/demo from cocoon-blocks-fw?
Haven't tried it for some time but if you follow the getting started
guide at
http://cocoon.zones.apache.org/daisy/cdocs-site-main/g2/1159.html and
add the sample block as further dependency to the myWebapp module
(make sure that you have installed them to the local Maven repo
before), you should be able to run them.
OK, thanks... but I need a little more know-how here:
1) Exactly which blocks do I need to add?
I'm not sure what the difference between cocoon-blocks-fw-sample,
cocoon-blocks-fw-demo1 and cocoon-blocks-fw-demo2 is. cocoon-blocks-fw-sample
contains three service servlets with a 'parent/child' and a 'uses' connection.
2) How do I install them to my local Maven repo?
Use 'mvn install'. If you invoke the Maven build from cocoon/trunk, the demos
should already be part of it. You can also change to
cocoon/trunk/core/cocoon-blocks-fw/cocoon-blocks-fw-sample and call 'mvn
install' from there.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Undefined property?
Hi,
Just a quibble, but... when I mvn jetty:run in cocoon-webapp, it
creates a directory named ${org.apache.cocoon.work.directory}... like
Ant does when you have an undefined property. The contents of this
directory is:
cocoon-logs/
log4j.log
...and nothing ever gets logged to this file, apparently... all kinds
of stuff is getting logged to the console, but this log4j.log file
remains zero-length.
cheers,
—ml—
Re: blocks-fw samples etc. (was Re: What is the deal with blocks)
On Jan 7, 2007, at 6:30 AM, Reinhard Poetz wrote: Mark Lundquist wrote: On Dec 28, 2006, at 10:00 AM, Reinhard Poetz wrote: Also: how do I run the sample/demo from cocoon-blocks-fw? Haven't tried it for some time but if you follow the getting started guide at http://cocoon.zones.apache.org/daisy/cdocs-site-main/g2/1159.html and add the sample block as further dependency to the myWebapp module (make sure that you have installed them to the local Maven repo before), you should be able to run them. I don't think so, now that I know the archetypes are for 1.0.0-M2-SNAPSHOT (or something like that...)? But see below... I'm not sure what the difference between cocoon-blocks-fw-sample, cocoon-blocks-fw-demo1 and cocoon-blocks-fw-demo2 is. cocoon-blocks-fw-sample contains three service servlets with a 'parent/child' and a 'uses' connection. I look at them a little bit. -sample is as you described, and where for each of the three services the embedded servlet is a SitemapServlet. In the case of -demo*, the embedded servlets are custom extensions of HttpServlet. -demo1 depends on -demo2 and has a connection to it. But anyway... 2) How do I install them to my local Maven repo? Use 'mvn install'. OK, that's all you meant :-) If you invoke the Maven build from cocoon/trunk, the demos should already be part of it. yes... and, it turns out that the -sample and -demo* are now included in the dependencies for cocoon-webapp. So, I had them all along. However, I have no clue what URI to request to access these samples. I poked around for a long time trying to figure it out, but with no luck (I'm still just trying to figure out all this stuff, and learn Maven in the process etc.). Any clues for me? thx, —ml—
RFC: CForms Roadmap
Hi All Now that Cocoon 2.1.11-dev runs Dojo 0.4.1, I think we have a solid platform to complete the modernisation of CForms client-side code. I hope the main outcomes of this will be : Leaner: only the resources that are used will be loaded by cforms Richer: more interactive widgets with wider x-platform support Cleaner: eliminate most of the messy script tags scattered through our forms Simpler: use more html templates to simplify our xslt (and simpler to adapt the widgets) Here is a list of specific goals I would love us to achieve for the next release. I hope to be working on this stuff, you would be very welcome if you'd like to join in If you would like to take on something from this list (or something I missed out) please discuss it on the dev list so no-one is duplicating effort. Replacements : Date/Time widget : replace MattKruse stuff with Dojo's implementation. Help validation popups: replace MattKruse stuff with a new Dojo implementation. Tabs: replace with Dojo Tabs RichText: replace htmlarea with Dojo Editor, using a new fi:styling, so htmlarea can still be used MultiValue Editor: re-implement as a Dojo widget MultiList (OptionTransfer) Selector: replace with a new Dojo widget Maps: not even sure our current one is working, replace with Dojo (Yahoo and Google) Possible Additions : Easy graphically rich buttons, dialogs, menus etc. Charts to plot user data Colour picker Re-sizable textarea Sliders: graphical selector for number ranges etc. Spinner: adjust values up and down with ± buttons Validation: plug in client-side validation where common datatypes exist between CForms and Dojo, make new ones Issues: We need to do this work in such a way that has the absolute minimum impact on existing cforms projects. eg. adapting Dojo widgets to work the CForms way and not the other way around. We need to make it easier to customise the style, layout and behaviour of our supplied widgets. We are probably going to have issues with i18n and l10n. Dojo is only just starting to deal with this area, while CForms has always delt with it. Dojo, performs i18n on the client instead of on the server as cforms does. Very few of Dojo's widgets are i18n enabled yet. Dojo uses a different format of i18n message dictionary than we do (all of this is kind of obvious). Most of the work above will involve either extending existing dojo widgets or making new ones. We ought to be adding i18n/l10n as we go along. We need to decide whether we want to keep our message dictionary format (transforming it on the fly for dojo) or start using Dojo's format (for widget internals). What did I miss out ? I hope this whets your appetite ! Let's get on with the replacements first !! WDYT ? regards Jeremy smime.p7s Description: S/MIME cryptographic signature
