I know markup inheritance (wicket:child/wicket:child) works at the Page
level but does wicket also support markup inheritance at the in Panel
level?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMA
Pardon my possible ignorance but didn't the need to use DAOs evaporate
once transparent persistence (eg., Hibernate, JDO) hit the streets a few
years back?
I always thought the DAO architecture was what we used in the old days
in the absence of mature transparent persistence solutions when we had
Great news, thanks!
> Yes, all components support markup inheritance. Give it a try!
>
> On Thu, May 29, 2008 at 9:14 PM, Chris Colman
> <[EMAIL PROTECTED]> wrote:
> > I know markup inheritance (wicket:child/wicket:child) works at the
Page
> > level but d
ome people still use dao to store finder/batch update methods.
>
> -igor
>
> On Thu, May 29, 2008 at 6:19 PM, Chris Colman
> <[EMAIL PROTECTED]> wrote:
> > Pardon my possible ignorance but didn't the need to use DAOs
evaporate
> > once transparent persistence (
Is there a wicket mode I can configure in which new markup (eg., new
markup variations) can be picked up at run time without restarting the
app?
In our app we can create/generate new markup at runtime. We don't want
to have to force a bounce of the web app for wicket to 'see' this new
markup.
---
Is it possible to route multiple bookmarks using mountBookmarkablePage
to the same page class?
Also, is it possible for the page to ask what it's bookmark (or URL) is?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional co
e web app each
time.
Is there an interface used to provide the markup to wicket for which we
can provide our own implementation and do the loading and caching of
markup and checking for new markup ourselves?
>
> Cheers,
> Jay
> On Thu, Feb 28, 2008 at 2:40 PM, Chris Colman
> <[EMAI
brien/wicket/apidocs/org/apache/wicket/marku
p/
> MarkupCache.html
>
> Cheers,
> Jay
>
> On Thu, Feb 28, 2008 at 4:01 PM, Chris Colman
> <[EMAIL PROTECTED]>
> wrote:
>
> > > Chris,
> > >
> > > Generating static markup files is not really th
/marku
p/
> MarkupCache.html
>
> Cheers,
> Jay
>
> On Thu, Feb 28, 2008 at 4:01 PM, Chris Colman
> <[EMAIL PROTECTED]>
> wrote:
>
> > > Chris,
> > >
> > > Generating static markup files is not really the "Wicket way" of
doing
> Chris,
>
> I'm not that familiar with the inner workings of the API but based on
the
> description in the Javadoc, I think you are going to need to provide a
> custom implementation of IMarkupCache.
>
> If you are looking for a simpler solution, you could enter an RFE for
new
> property on iMar
When using AJAX with wicket where are the instructions on where and how
to make the .js available to the browser?
Eg., resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js
Do we have to create a directory under project/web called
resources/org.apache.wicket.ajax.WicketAjaxReference
under
> classes/org/apache/wicket/ajax
>
> -igor
>
>
> On Thu, Feb 28, 2008 at 9:47 PM, Chris Colman
> <[EMAIL PROTECTED]> wrote:
> > When using AJAX with wicket where are the instructions on where and
how
> > to make the .js avai
Problem found: Was a problem with
ase file a bug report
>
> -igor
>
>
> On Thu, Feb 28, 2008 at 11:26 PM, Chris Colman
> <[EMAIL PROTECTED]> wrote:
> > Problem found: Was a problem with
ted components/behaviors. i guess wicket ignores these if the
> page is stateless, which woud be a bug...
>
> -igor
>
> On Fri, Feb 29, 2008 at 12:50 PM, Chris Colman
> <[EMAIL PROTECTED]> wrote:
> > I've tried 1.3.1 and still no luck in getting wicket to inject the
> > appropriate
I've tried 1.3.1 and still no luck in getting wicket to inject the
appropriate
I tried that by adding a TextField - still no joy.
> no. webpage is the correct choice. as a workaround you can make the
> page stateful
>
> -igor
>
>
> On Fri, Feb 29, 2008 at 1:04 PM, Chris Colman
> <[EMAIL PROTECTED]> wrote:
> > The class derives
How do I force a page to be stateful?
> I tried that by adding a TextField - still no joy.
>
> > no. webpage is the correct choice. as a workaround you can make the
> > page stateful
> >
> > -igor
> >
> >
> > On Fri, Feb 29, 2008 at 1:0
at...
MyServer
org.apache.wicket.protocol.http.WicketServlet
applicationClassName
com.sas.av.ui.wicket.MyApp
1
MyServer
/content/*
>
>
> -Matej
>
> On Sat, Mar 1, 2008 at 7:19 AM, Chris Colman
> <[EMAIL
I have a similar problem but it's to do with creating new markup
variations - each new one I add requires a server restart for it to be
detected. Apparently customers don't like that for some strange reason
=)
I think your problem is easily solved - you just have to run you
production server in de
> On Sat, Mar 1, 2008 at 3:10 PM, Chris Colman
> <[EMAIL PROTECTED]> wrote:
> > I have a similar problem but it's to do with creating new markup
> > variations - each new one I add requires a server restart for it to
be
> > detected. Apparently customers don&
Thanks, I'll give that a go.
> i think it is:
>
> getapplication().getmarkupsettings().getmarkupcache().clear(); which
> will clear the entire cache.
>
> there is also a jmx hook.
>
> -igor
>
>
> On Sat, Mar 1, 2008 at 3:25 PM, Chris Colman
> <[
> > I kinda miss the point of this entire thread? What exactly doesn't
> > work? Are you getting no javascript references written to your
> > section?
Correct.
> > How did you map the WicketFilter?
>
> Whoooh! I think you might have found the problem for us.
Unfortunately we still have the pr
> > first you have to realize that this is a corner case. doing
> > constructor injection with actual component instances is pretty
rare.
>
> I find myself wanting to do it quite often with side-bar panels that
> contain a mix optional items
I find that also - a whole branch of the page hierarchy
Back in 1.2.4 days there was a fully self contained wicket quickstart
zip that contained everything needed to build and deploy some sample
wicket apps to a servlet container.
Is there any such zip for 1.3.x?
-
To unsubscribe, e-m
I found the wicket-examples directory in the wicket 1.3.1 zip. We've got
that building an running now.
Thanks,
Chris
>
> still there in svn, and there is also a maven
> archetype...http://wicket.apache.org/quickstart.html
>
> -igor
>
>
> On Sun, Mar 2, 2008 at 3:
We store markup in a separate external directory to the source code and
it works all well compiling under ant but we're now compiling
wicket-examples using maven and we've moved the markup into an external
directory and maven now complains that the markup files can't be found.
Is there a way to tu
> Or don't store the markup in an external directory. It will make
> building reusable components a lot harder.
...and make it mandatory to bounce the enterprise web app whenever a
designer makes a change to the markup which is not an option for this
app unfortunately.
--
> Personally, I like to approach everything "enterprisey" by using
services
> > which can be split into different areas of functionality.
That sounds very similar to the highly productive Exposed Domain Model
POJOs pattern as described in "POJOs in Action". We've used that pattern
very successfull
I've been using wicket for quite some time now and I just have a
question regarding the reason why wicket parameters are sent as a
sequence of
/param-name/param-value/
pairs instead of the traditional ?param-name=param-value& etc., query
strings.
Was the reason that it was believed that /p/v pai
I need to store some data on a per session basis.
What's the best approach in a wicket environment?
1. Should I create my own session factory and create a custom session
class that stores the data as an attribute?
OR
2. Go the old fashioned route and retrieve the J2?E HttpSession and
store it i
7;s not such a problem with us all living together in this
global village these days.
We've worked with a Boston company before back in 2000. These days of
Skype and video conferencing would make that even easier and less
expensive.
Regards,
For the first time I had to provide an external link to the outside from
a Wicket app - heh, it happens sometimes ;)
One thing I discovered that I couldn't find documented in the
ExternalLink class was that you need to put a 'http://' prefix prior to
the URL so that the URL gets formed properly -
I have a number of pages that display a list of items and am wondering
about the best approach to implementing them in Wicket.
To date I have created a single panel that contains the list and the
markup for that panel holds the discrete markup elements for the fields
in each item of the list.
Ano
> Well here's our story, if it helps you.
Here's ours as well:
Wicket (+some Echo2) + "exposed POJO model" managed by Javelin + JPOX
for the ORM.
Having come from a JSP/Struts + home grown ORMish kind of framework
using proxy/reflection implementation (yuck) this new set of tools is
***ken aweso
I have content that I render that may or may not have a URL associated
with it. I don't want to display anything if the URL is blank.
I use ExternalLink for the URLs. As I place a reference to the link in
my markup I need to instantiate an ExternalLink object in the
corresponding page/panel classe
s have a http:// in front of it making a trivial test not
possible.
>
> -igor
>
>
> On 10/2/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> >
> > I have content that I render that may or may not have a URL
associated
> > with it. I don't want to
age-
> From: Martijn Dashorst [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 3 October 2007 4:36 PM
> To: users@wicket.apache.org
> Subject: Re: Making ExternalLink invisible: test for what?
>
> why not use the setVisible method?
>
> link.setVisible(StringUtils.isNotBlank(
To date we've built all of our static pages in Wicket and all dynamic
pages/user input forms etc., in Echo because it provides a pure Java (no
need to write any JavaScript) solution to generating AJAX powered pages.
The problem is when users switch from Echo pages back to Wicket pages
using the br
> Short answer : You do not have to write a single line of
javascriptcode
> to use wicket ajax behaviors. This is already done for you.
Great!
> Regarding browser differences, I belive they are handled(by
> wicket-ajax). AFAIK in beta 4 even safari works:)
Another question: How does Dojo fit int
I've created a form and set up some validators on various fields. When
there is an error and the page is redisplayed showing the errors none of
the previous values that the user typed in are there.
Is there an easy way to preserve the values already entered by the user?
I tried overriding onError
import wicket.model.PropertyModel;
import wicket.markup.html.image.*;
import wicket.extensions.markup.html.captcha.*;
import java.lang.*;
import java.util.Random;
// -[Class]-
/**
* Information Request Page.
*
* @author Chris Colman
*/
public
class InformationRequestPage extends StandardPa
Oh yeah, I'm using Wicket 1.2.6 if that has any bearing on the
situation.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
27;extended' page where the form component is added in mark up inside a
... form sits in here ...
construct.
> On 11/1/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> >
> > Oh yeah, I'm using Wic
> can you make sure your servlet mapping is of form /foo/*
>
> -igor
Yes it's of that form.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> I found an excellent thread in the archives that explains this topic
very
> well - I swear I searched before, but obviously with the wrong
keywords ;)
>
>
http://www.nabble.com/Multiple-wicket%3Achild-tags-in-the-same-page-tf37
75143.html
>
> Multiple child/extends pairs (where you have to see su
rticular one?
All components don't preserve their values.
> try it without that funky onerror() override.
I commented out the funky onerror() override and the problem still
exists.
H, getting curiouser and curiouser!
>
> -igor
>
> On 11/2/07, Chris Colman <[EMAIL P
> > It would be quite feasible to add support for multiple overridden
> > sections using the above tag names while remaining backwards
compatible
> > with existing markup by continuing to support the old
> > tags working the way they always have.
>
> It's kind of a predictable answer, but the bes
> > There's nothing I would love more right now than to have to time to
> > implement a patch to support multiple overridden sections in a
wicket
> > page but unfortunately time is one thing I don't seem to have much
of
> > these days. I can't believe 2007 is almost over - heck, where did
this
> >
Could it be because the form page is bookmarkable?
> thats odd, all the values should be preserved, thats our rawinput that
> all formcomponents have. Do you have a repeater/listview around your
> formcomponents.
>
> On 11/1/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> &
Ok, I'll do that. The problem probably won't happen in the quickstart
form ;)
>
> why dont you submit a quickstart and then we can figure out why its
> happening
>
> -igor
>
>
> On 11/2/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> > Cou
Is there a page with guidelines on making a wicket quickstart?
> why dont you submit a quickstart and then we can figure out why its
> happening
>
> -igor
>
>
> On 11/2/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> > Could it be because the form page is bookm
> I was wondering if anyone has started a Wicket project (instead of the
JSF
> endorsed one). I would hate to recreate the wheel if someone has
already
> started a similar project.
Come on! Recreating the wheel is what us software engineers do best!
Imagine how boring the wheel would be if we hadn
> if i were you i would use tags other then extend and child just so you
> dont conflict.
Yes Stefan, I would think that would be a better approach to use a new set of
tags. It also allows you to choose more correct naming (because inheritance
isn't actually a parent/child relationship so the wo
> thanks for that advise.
>
> hey chris, keep your fingers crossed. finally you could get your
> wicket:abstract-wicket:override ;)
That would be magic!
Though I like the suggestion that someone made that we replace 'override' with
implements. 'Abstract' has no implementation. 'Implements' prov
> the complement to abstract is implement not override... names are
> important.
Arh, sorry, I made my last post before reading yours Igor. Yes, I agree
abstract/implement make a great complimentary pair.
-
To unsubscribe, e-mai
> Wouldn't this essentially be the same as using id="header"/> and using WebMarkupContainers on the java side?
> I.e.:
>
> Base
>
Structural markup goes here (see below for explanation of this)
>
More structural markup goes here
>
And again more structural markup goes here too
>
> P
n to
handle both multiple (if names are provided) and fallback to single (if no
names are provided) - single is then just an ordinary case of multiple where
n=1.
>
> However, I'll consider using a different name and separate implementation
> for the prototype.
>
> -- Stefan
> > Wouldn't this essentially be the same as using > id="header"/> and using WebMarkupContainers on the java side?
>
>
> yes it would be exactly the same thing.
If you think that these are the same then you've missed some vital plot
points of the movie that it child/extend.
---
> Hmmm... more tags? I thought you guys liked Wicket because it's plain
html
> support. Now looks like there's a big interest in having more tags. If
> this is true, why don't we go back a few years, or move to JSF? Let's
give
> Wicket support to Tag Libraries too :)
>
These aren't just like othe
you could be 1000x times more productive.
Someone asked for another explanation of the difference so I'll do that again
in a following post.
>
>
>
> Chris Colman wrote:
> >
> >> Wouldn't this essentially be the same as using >> id="header&
> > Given these subtle problems with this approach, I admit I'm warming
to
> > the multiple extend/child idea.
>
> im oposite - if i have X extends in a page, whose extend should be
> preferred (e.g: manipulating the head or a part outside of itself) ?
I'm not sure I understand the issue you ra
> > And if somebody really needs 5 child areas, something else might be
even
> > messier than the page's constructor. I rather think that 2, 3 or in
rare
> > cases even 4 ids could make sense.
>
> i must disagree - i have a basepage which defines the default layout
on a
> project, i.e. header, top
> Chris Colman schrieb:
> > The beauty of the multiple extend/child idea is that it's not a
> > completely new concept we're talking about here - it's merely an
issue
> > of supporting n>1 instead of arbitrarily fixing n=1 like it is now.
>
> 1 Que
> > How can it get messy when it's not yet possible to do in wicket?
>
> i believe it has been shown multiple times already that it CAN be done
> with vanilla wicket...
I didn't like the look of any of those 'coded' solutions. They were not
from the coding elegance book I've read. They also mean
> a lot of people are saying that this can be implemented with panels,
> and that is true. but actually implementing this with fragments will
> make it look very similar to this new strategy and does not have the
> id collission problem, because components ARE nested in two different
> containers:
Presumably the coded work arounds that don't rely on child/extends mean
that the structural markup of each page is used instead of just that of
the base page - and that would spell maintenance issues. Without using
child/extend then ALL the structural markup in each page is used for
each render - N
> Korbinian Bachl wrote:
> > you missed solution3:
> > the real-wicket-way(tm) for multiple content-places in a tied
page-area:
>
> Whaaa, I seriously hope this is not the real-wicket-way! My brain
hurts!
>
> A framework is supposed to make things easy and readable! The code
below
> is just way t
> and in extending classes you can easily do this:
>
> protected void initialize() {
>
> addToAnything(new AnyPanel("id"));
> addToAnything(new AnyPanel2("id2"));
> }
So now you're proposing the Java code is defining the layout of
components? That's what the markup's job is
> ok tell me with 2 examples what is soo different about having 2 panels
(or
> fragments)
> in a page and implement that in a sub page or having 2 wicket childs
in a
> page and implement those in a sub page.
Ok, here we go... (well one example at least - it's getting late here ;)
)
I'm not sure
> public DerivedPage extends BasePage {
>
> private String name;
>
> public DerivedPage(String name) {
> super();
> this.name = name;
> }
>
> public abstract addAbstract1(String abstractId1) {
> add(new NamePanel(abstractId1, name));
> }
> }
>
> This
> ...
>
> 5) Conclusion
>
> In conclusion, the proposed change:
> - is useful
> - does not have to be used if you don't like it
> - is 100% backwards compatible
> - it introduces no new tags (if using child/extends)
>
> I also do not see any real issues. This is purely abo
> > The advantage of having this separate project
> > is that such inheritance would be available for people who like it,
> > and hey, maybe in the longer term you have something that works so
> > good that you can convince people based on something that works.
> > Executable code works much better
> heh, wellyou can be against this, but i think if we take a vote
> right now most core-devs with binding votes will vote this down
I still can't see the reason for the negativity of some of the
core-devs: this is an existing feature.
If the feature sucks so bad why did people have the in
> That is what I'd suggest as well, since it involves the least amount
of
> change. As an added bonus, if no id's are added and 2
> sections are used, it could throw an exception (which it currently
does
> not do, it just silently ignores the second ).
That would be magic!
While we're at this ep
> Hi,
>
> Actually, Wicket already works like this. It does *NOT* require the
> , and if it's not present it just renders the contents
of
> the . (Just tested this with beta4).
Awesome!
[This behaviour must have changed since 1.2.6 because I tried removing
the tag in a derived page using this ve
> > > i plan to use JPA together with Wicket. Are there any
battle-proven
> > > best-practices out there of how to handle EnityManagers and
> Transactions?
> > >
> > > What do other people use (no, not the spring crowd ;) ?
> > >
> > > One EntityManager per Request seems to be the obvious idea and
> I give up. Looks like this enhancement is really receiving positive
votes.
> :)
:) :) :) :) :) :) :) :)
Just some of the many happy faces!
> In my second reason, I point to something that is... the _core_ of
wicket:
> binding Java objects (Components) to HTML tags. So, not having this
>
I'm using the wicket extensions CAPTCHA feature which works perfectly
except:
I know the purpose of CAPTCHA is to make the text unreadable to a
certain extent but it's *TOO* good at making the text unreadable - such
that humans often get it wrong too.
I have a client who has complained that while
Good idea! I tried throwing out all the letters and using only numbers
but even then there was a lot of ambiguity between 1 and 7.
I might try going back to letters and avoiding the letters that you
mention.
> But yeah, about 10% of the time, they get pretty bad.
Yeah it gets so hard to read
> i hope you guys realize that this isnt a wicket issue, its an issue
> with the captcha lib that wicket uses - thats what is generating the
> image.
I realized that it was a third party thing. If it was written by the
wicket devs it would rock like everything else they write!
> so why not simply
The trouble is that the answers to the kitten questions usually have a
small number of possible combinations: 1 - 5 roughly so on average a
robot may be successful 20% of the time.
> thoof.com has a better captcha: select the kittens. I'd love to know
> if it works for them or not.
>
> Martijn
-
> Chris Colman schrieb:
>
> > The obvious benefit in such an approach is that your POJO model and the
> > services that you provide to implement business rules etc., remain
> > completely portable to different persistence engines - ie., no vendor
> > lock in.
>
&
> Evan Chooly wrote:
> >
> >> Do you know if theres any plans on making a maven2 archetype for
> qwicket?
> >
> > That's a definite feature i plan on adding as soon as I can. As a
> > noted maven hater, though, it'll take some time and libations to
help
> > me swallow my pride. :)
> >
>
> Good l
> Chris Colman wrote:
>
> It seems it's also possible for a few other ORM tools to conform to
that
> standard. Apart from Hibernate and JPOX you've got TopLink, Cayenne
and
> others.
That's my point.
>
> Which would you rather depend on; exPOJO or JPA?
ORM but your company or
client hasn't decided on one yet - just pick your favorite ORM and then
start development while you're waiting on their decision. When they
finally make up their mind you'll have an easy time porting your app.
>
> Chris Colman wrote:
> >
> > ex
> Hello
>
> I've browsed over the wicket documentation and examples. There are a
> couple of things I don't seem able to determine. So I would really
> appreciate your input on this questions.
>
> 1. Can I write a web application without coding any HTML
whatsoever?...
> I mean, is there some kind o
I have a client who employs a professional SEO guy. He's told the client
that my use of /productId/3 (as per the wicket standard) is not kosher
with the search engines and that I should be using the traditional
?product=3 query stuff as the search engines produce better rankings for
pages with thos
s serving the wicket pages.
>I've already used a similar implementation to this:
>http://techblog.molindo.at/2011/03/serving-wicket-resources-from-cdn.ht
ml
>
>Regards,
>
>Jan
>
>Von: Chris Colman [chr...@stepaheadsoftware.com]
What is involved in telling wicket to fetch its js (jquery etc) from a
different server. It doesn't have to be a true CDN server just a
different server to the one the wicket app is running on.
Would this require using wicket-cdn or is there an easy way to just tell
wicket to fetch its js from a
fferent server
>
>Hi,
>
>getJavaScriptLibrarySettings().setJQueryReference(new
>UrlResourceReference("some url"))
>
>Martin Grigorov
>Wicket Training and Consulting
>
>
>On Sat, Feb 1, 2014 at 8:02 AM, Chris Colman
>wrote:
>
>> What is involved in
We are using Wicket with Bootstrap which is fine except for modal
window.
With Wicket it appears as though the modal window provides all the
markup for the out modal 'window'. We can provide HTML for the panels
within that but the outer modal seems to be Wicket generated.
This seems to be causing
rule that sets the width for any .form-control in .wicket-
>modal.
>You can either use LESS/SASS to generate different rules for the
different
>screens or with CSS media queries.
>
>Martin Grigorov
>Wicket Training and Consulting
>
>
>On Tue, Feb 18, 2014 at 8:04 AM, Chris
ow used in this 'generic' way.
Is there any work around for this?
Yours sincerely,
Chris Colman
Pagebloom Team Leader,
Step Ahead Software
pagebloom - your business & your website growing together
Sydney: (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120
Email: chr...@
Hi fellow wicketeers!
We all know that Wicket has to be the most awesome and productive Java
UI framework around but I am worried when I point new clients to the
Wicket website because it's look and feel is possibly a little dated or
'2007ish style'.
I feel like the look and feel of the Wicket
kyll has issues/limitations.
Regards,
Chris
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Wednesday, 12 November 2014 7:21 PM
To: users@wicket.apache.org
Subject: Re: Wicke website makeover time?
Hi,
On Wed, Nov 12, 2014 at 9:45 AM, Chris Colman
wrot
t am not sure if/how that
works
- how to publish the site (currently generate, svn commit, but if
guide is part of our build (to enable live, compiling examples) how
does that integrate in the site workflow...
Martijn
On Wed, Nov 12, 2014 at 9:21 AM, Martin Grigorov
wrote:
> Hi,
>
>
> O
n commit, but if
> guide is part of our build (to enable live, compiling examples) how
> does that integrate in the site workflow...
>
> Martijn
>
>
> On Wed, Nov 12, 2014 at 9:21 AM, Martin Grigorov
> wrote:
> > Hi,
> >
> >
> > On Wed, Nov 12, 2014 at
>> I think a multi phase approach might have more chance of success - as
I
>> said in my immediate previous post if we could live with jekyll
source
>> for phase one (even though it may not be ideal) then we can keep most
of
>> the current content source 'as is' and simply choose a decent modern
>>
formation is perhaps a bit too much.
--
Guillaume
On Fri, Nov 14, 2014 at 1:14 PM, Chris Colman
wrote:
>>> I think a multi phase approach might have more chance of success -
as
> I
>>> said in my immediate previous post if we could live with jekyll
> source
>>> f
1 - 100 of 613 matches
Mail list logo
