You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Martin Kersten <ma...@gmail.com> on 2013/10/13 23:51:26 UTC
Dynamic Loading of Templates
I am currently trying to setup a good way to test my components in
isolation. I do not like the idea to create a Page for every component
setup.
So what I want is writing a simple Page with a single dynamic component.
Digging into the code I notice that we got a DynamicTemplateParser service
for parsing any resource and get a dynamic template.
So this looks like something I just need. Using a Junit Rule I will be able
to drive this Dynamic parsing process providing a constructed string based
HTML representation of the component template.
Now the question is can I do this with a page? I mean just a page using a
rendering command like the component. Thinking about it it would be better
to use a custom DynamicPage which parses its template based on a Page
parameter.
Does anyone have some ideas or remarks why this is (im)possible? Anyone
does this before?
Cheers,
Martin (Kersten),
Germany
Re: Dynamic Loading of Templates
Posted by Martin Kersten <ma...@gmail.com>.
>
> Change that give us a resource that is not file based. And what do we get?
> VirtualResource extending Resource why?
>
>VirtualResource is in an internal package (org.apache.tapestry5.internal
.util) so it is *not* meant to be outside Tapestry's source code.<
Even more kind of a downer.
Dont ask about Resource either... 2008 Resource is filebased.
>
> org.apache.tapestry5.ioc.Resou
rce is *not* file-based. I have no idea why you said that statement. You
can implement it in any way you want, including completely dynamically and
just in memory, as long as its immutable. Tapestry itself does that for
gzipped, minified and combined JavaScript files.<
? I implemented a string resource. I got 15 methods (or 10 wasnt counting
but way too much) half of it dealing with files directly others where
related to fies. I managed my stuff with only two methods so why having the
rest? I just see it everywhere. This framework was build one piece at a
time. But there is a lack of letting the methods and functionality condense
uppon objects. Its somehow the functionality is steered away from the
objects.
Just again where is my Page.getTemplate() method. Would solve all the
issues related to template loading we have seen since 2008. People are
constantly asking for loading templates from databases. Why not? 5 years in
a row.
Look at this:
Page {
@Inject
TemplateCache cache;
@Inject
TemplateParser parser;
MyTemplate getTemplate() {
Object key = getTemplateIdentity();
MyTemplate template = cache.get(key);
if(template != null)
return template;
else {
template = loadTemplateFromSource(key);
cache.put(key, template);
}
}
}
Done. Simple. Straight forward. Cache is just an option not hardwired into
the dynamic parser. Really a parser with cache facility? No option to
switch it off. See and this is just one issue. I got over 20 by now all
things I would change in tapestry. Some are for the IOC some are for the
other things.
I tell you a strange story lately happend to me. I debugged. Yeah lots of
proxies, no source code available (why?). So lots of magic I can not
understand. I step blindly in every method a i see source ah i dont see
source I see source and I dont see source. So lots of magic.. I dont like
magic. If I want magic I go for microsoft and closed source. Well sadly
Eclipse isnt even providing byte code either... . So in all this source
reading and debugging - Yet again the branch flow in those longer methods
is crazy - I never came aware of that the PerThread Service is managed by
the proxy.
The registery creates the proxy (where is my source code! I want source
code! At least in developer mode!) and the proxy uses a creator that
provides per thread value functionality. Dude I am using tapestry for half
a year now and I forgot about that basic feature. Tapestry is one of those
magic frameworks I want to put aside but Tapestries value still outweights
those down time experiences by far.
And lucky me I do test first. I guess someone who does not test or even
test later will waste so much time figuring out how things go... .
So take this Template stuff for free. People are bagging for the load from
database thing for ages now. Nothing happend and see what I came up with
easily in five minutes thinking. Just plain old OOP translated into DI
world.
The biggest flaw in tapestry all way around, everything is final, hard
wired and only flexible if there was an urgent need to do so. Simply the
methods are too long. Just as the Spring framwork suffered from it in 2003
Tapestry still does... .
Who is testing this branch graves? In 2008 I talked about this if illness
spreading around the sources in tapestry. Every if is a cross road in the
path flow. You can not test those think about it 5 unrelated ifs:
if(a) {}
if(b) {}
if(c) {}
if(d) {}
if(e) {}
I found this often when I look into the IOC makes me crazy. Its a nightmare
to read and test.
See this above has 2⁵ paths makes it 32 paths to test. And now lets take a
look at if else
if(a) {} else if(b) {} else if(c) {} else if(d) {} else if(e) {} this makes
it 6 paths nothing more.
But the ifs arnt related you can not do the else stuff. Wow you found a new
method to extract.
When ever you have two ifs that can not be joined by else then you have two
unrelated ifs.
That means you have found at least one new method (but often its two - one
for every if).
Try it refactor the methods for this branch complexity (mcCabe anyone?)
reduction. It will
become much more simplier.
Cheers,
Martin (Kersten)
PS: Consider the Template example above a contribution to 5.5 or better 6.0.
2013/10/18 Thiago H de Paula Figueiredo <th...@gmail.com>
> On Fri, 18 Oct 2013 13:51:56 -0300, Martin Kersten <
> martin.kersten.mk@gmail.com> wrote:
>
> Dont ask about Resource either... 2008 Resource is filebased.
>>
>
> org.apache.tapestry5.ioc.**Resource is *not* file-based. I have no idea
> why you said that statement. You can implement it in any way you want,
> including completely dynamically and just in memory, as long as its
> immutable. Tapestry itself does that for gzipped, minified and combined
> JavaScript files.
>
>
> Change that give us a resource that is not file based. And what do we get?
>> VirtualResource extending Resource why?
>>
>
> VirtualResource is in an internal package (org.apache.tapestry5.**internal.util)
> so it is *not* meant to be outside Tapestry's source code.
>
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<us...@tapestry.apache.org>
>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Dynamic Loading of Templates
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 18 Oct 2013 13:51:56 -0300, Martin Kersten
<ma...@gmail.com> wrote:
> Dont ask about Resource either... 2008 Resource is filebased.
org.apache.tapestry5.ioc.Resource is *not* file-based. I have no idea why
you said that statement. You can implement it in any way you want,
including completely dynamically and just in memory, as long as its
immutable. Tapestry itself does that for gzipped, minified and combined
JavaScript files.
> Change that give us a resource that is not file based. And what do we
> get?
> VirtualResource extending Resource why?
VirtualResource is in an internal package
(org.apache.tapestry5.internal.util) so it is *not* meant to be outside
Tapestry's source code.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Loading of Templates
Posted by Martin Kersten <ma...@gmail.com>.
> I'd love to see your source code... it must be out of this world!!!
Nah. Its just more true to test driven development and agility. You know
small methods, DRY, KISS bla bla bla.
It's simple as this. Tapestry is service heavy. Why do not have
Page.getTemplate() (as option of cause). I asked for it in 2008? Nothing.
This whole overcomplicated under-engineered complex with the selectors and
caches, template locators bla bla. Why? Start thinking about
Page.getTemplate(). Get it right. Then ease implementation details. Why is
the dynamic tempalte parser is having a cache? Why? That's not flexible,
its not a parser if it also caches. Its a hybrid. Its wrong design by the
letter. Its a parser. Nothing more and I know no template parser that
caches per default that caches in any way you cant turn off, that caches at
all. Thats this feature rich stuff I dislike. Thats what it makes stiff,
unfocused and hard to understand.
Every service I am touching I end up in hacking. I copy the code and
rewrite its behaviour. I do not overwrite I replace. And I test everything
to be sure if tapestry sources change I will see the exact spot that breaks
now. Thats why I can do it in first place.
Just try to simplify tasks around providing easier support for someone
implementing Page.getTemplate. It becomes so clear that Tapestry is lacking
in this realm. It would have been so easy to do this for me. But no. I have
to hack around and search and do. 4hours or more. Reading sources, missing
some important stuff. Bla bla. I dont like it it isnt productive.
Why cant I load templates from database? Because there is no way to get
page.getTemplate() to work easily. It should be one liner. Inject a good
abstract service for it give it the string content done.
Dont ask about Resource either... 2008 Resource is filebased. Change that
give us a resource that is not file based. And what do we get?
VirtualResource extending Resource why? Why not put a Virtual Resource up
the resource. I mean a resource that is virtual or not but it must not be a
file... . It was implemented the other way around. So I have to use
unsupported operation exception to guard against using the resource in a
way one can only treat a File based resource. If you need to use
unsupported operation the design is wrong. Periode. Its like having an
inmutable list and having to prevent those modification operation. I know
why java.util lives with it. But Resource here is a main concern. And I
just stop here. I collect every aspect I dislike about tapestry and want to
change and I also collect ideas how to simplify and why. Just for personal
use and as a learning experience. Guess what I have more then 20 items.
I love the way tapestry is doing the rendering and all. Its good clean
simple. But I do not touch the code. Its not straight forward its around
two edges. And this does not have to do with services. Its all about doing
something certain until it works without the simplification step and the
refactoring at the end.
If you want we can do a remote programming session (15min perparation,
15min talking). Lets say we both take one big fat class / service
implementation of the IOC and refactor (no rewrite, no reimplementation
only refactoring). And we see where we both end. And then we compare
results using skype asking questions, sharing desktops and such. The way
programmers learn best.
Then we can check whether my complains are valid or not. If I am right we
got tons of things that will improve naturly or if i am wrong it all turns
out good enough and no change would be worth the afford. (Might sound like
a challenge but its not, its an opportunity).
Cheers,
Martin (Kersten),
Germany
2013/10/18 Lance Java <la...@googlemail.com>
> Strange to hear you talk that way of the tapestry implementation. I
> personally think it's some of the best code I've seen and I genuinely think
> that familiarising myself with the tapestry source code has made me a
> better developer. Everything is overridable and there are many seams where
> you can intercept and tweak the core implementation. The test coverage is
> amazing!!
>
> Perhaps one of the negatives is that there are many one or two method
> services that all work together. It can be difficult to find exactly where
> you should be looking / tweaking. But the benefit is that services are
> simple to tweak and test.
>
> I'd love to see your source code... it must be out of this world!!!
>
>
> On 17 October 2013 16:55, Martin Kersten <martin.kersten.mk@gmail.com
> >wrote:
>
> > Well my english is not good enough :). And it would be a mixed blog
> because
> > i dislike most of the way its implemented I always ask my self why
> tapestry
> > is such overly complex and also lacks refactoring (in my opinion) I like
> > the tapestry sources its above average but nothing more. And after
> reading
> > tapestry code I just have the mixed feeling of numbness. Cant help but I
> > feel differently for different source styles. Some letft me cristal
> clear,
> > some warm and relaxed, other kept me alerted and the tapestry style makes
> > me numb. Cant help it. Well thats the way it is. My keeps me warm and
> > relaxed so its something biased I guess. But some code I write in hurry
> > leave my with slightly headaches when I read them later on. Maybe I am
> just
> > overly sentisive since my near death illness and strange recovery. Well
> > dont mind :-).
> >
> >
> > 2013/10/17 Thiago H de Paula Figueiredo <th...@gmail.com>
> >
> > > On Thu, 17 Oct 2013 11:17:26 -0300, Martin Kersten <
> > > martin.kersten.mk@gmail.com> wrote:
> > >
> > > I collect this stuff I do for blog posts. But I need to find a native
> > >> english speaker with a tapestry background first :).
> > >>
> > >
> > > Some of the best blog posts about Tapestry are written by Igor
> Drobiazko
> > (
> > > http://blog.tapestry5.de, which is German, and Taha Hafeez (
> > > http://tawus.wordpress.com/), which is Indian (guys, please correct me
> > if
> > > I'm wrong), so I don't see the need of a native English speaker (as
> long
> > as
> > > the person knows Tapestry and writes good English, of course). :)
> > >
> > > --
> > > Thiago H. de Paula Figueiredo
> > > Tapestry, Java and Hibernate consultant and developer
> > > http://machina.com.br
> > >
> > >
> ------------------------------**------------------------------**---------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<
> > users-unsubscribe@tapestry.apache.org>
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
>
Re: Dynamic Loading of Templates
Posted by Lance Java <la...@googlemail.com>.
Strange to hear you talk that way of the tapestry implementation. I
personally think it's some of the best code I've seen and I genuinely think
that familiarising myself with the tapestry source code has made me a
better developer. Everything is overridable and there are many seams where
you can intercept and tweak the core implementation. The test coverage is
amazing!!
Perhaps one of the negatives is that there are many one or two method
services that all work together. It can be difficult to find exactly where
you should be looking / tweaking. But the benefit is that services are
simple to tweak and test.
I'd love to see your source code... it must be out of this world!!!
On 17 October 2013 16:55, Martin Kersten <ma...@gmail.com>wrote:
> Well my english is not good enough :). And it would be a mixed blog because
> i dislike most of the way its implemented I always ask my self why tapestry
> is such overly complex and also lacks refactoring (in my opinion) I like
> the tapestry sources its above average but nothing more. And after reading
> tapestry code I just have the mixed feeling of numbness. Cant help but I
> feel differently for different source styles. Some letft me cristal clear,
> some warm and relaxed, other kept me alerted and the tapestry style makes
> me numb. Cant help it. Well thats the way it is. My keeps me warm and
> relaxed so its something biased I guess. But some code I write in hurry
> leave my with slightly headaches when I read them later on. Maybe I am just
> overly sentisive since my near death illness and strange recovery. Well
> dont mind :-).
>
>
> 2013/10/17 Thiago H de Paula Figueiredo <th...@gmail.com>
>
> > On Thu, 17 Oct 2013 11:17:26 -0300, Martin Kersten <
> > martin.kersten.mk@gmail.com> wrote:
> >
> > I collect this stuff I do for blog posts. But I need to find a native
> >> english speaker with a tapestry background first :).
> >>
> >
> > Some of the best blog posts about Tapestry are written by Igor Drobiazko
> (
> > http://blog.tapestry5.de, which is German, and Taha Hafeez (
> > http://tawus.wordpress.com/), which is Indian (guys, please correct me
> if
> > I'm wrong), so I don't see the need of a native English speaker (as long
> as
> > the person knows Tapestry and writes good English, of course). :)
> >
> > --
> > Thiago H. de Paula Figueiredo
> > Tapestry, Java and Hibernate consultant and developer
> > http://machina.com.br
> >
> > ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<
> users-unsubscribe@tapestry.apache.org>
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
Re: Dynamic Loading of Templates
Posted by Martin Kersten <ma...@gmail.com>.
Well my english is not good enough :). And it would be a mixed blog because
i dislike most of the way its implemented I always ask my self why tapestry
is such overly complex and also lacks refactoring (in my opinion) I like
the tapestry sources its above average but nothing more. And after reading
tapestry code I just have the mixed feeling of numbness. Cant help but I
feel differently for different source styles. Some letft me cristal clear,
some warm and relaxed, other kept me alerted and the tapestry style makes
me numb. Cant help it. Well thats the way it is. My keeps me warm and
relaxed so its something biased I guess. But some code I write in hurry
leave my with slightly headaches when I read them later on. Maybe I am just
overly sentisive since my near death illness and strange recovery. Well
dont mind :-).
2013/10/17 Thiago H de Paula Figueiredo <th...@gmail.com>
> On Thu, 17 Oct 2013 11:17:26 -0300, Martin Kersten <
> martin.kersten.mk@gmail.com> wrote:
>
> I collect this stuff I do for blog posts. But I need to find a native
>> english speaker with a tapestry background first :).
>>
>
> Some of the best blog posts about Tapestry are written by Igor Drobiazko (
> http://blog.tapestry5.de, which is German, and Taha Hafeez (
> http://tawus.wordpress.com/), which is Indian (guys, please correct me if
> I'm wrong), so I don't see the need of a native English speaker (as long as
> the person knows Tapestry and writes good English, of course). :)
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<us...@tapestry.apache.org>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Dynamic Loading of Templates
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 17 Oct 2013 11:17:26 -0300, Martin Kersten
<ma...@gmail.com> wrote:
> I collect this stuff I do for blog posts. But I need to find a native
> english speaker with a tapestry background first :).
Some of the best blog posts about Tapestry are written by Igor Drobiazko
(http://blog.tapestry5.de, which is German, and Taha Hafeez
(http://tawus.wordpress.com/), which is Indian (guys, please correct me if
I'm wrong), so I don't see the need of a native English speaker (as long
as the person knows Tapestry and writes good English, of course). :)
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic Loading of Templates
Posted by Martin Kersten <ma...@gmail.com>.
Thats what I ment by stripping of the cache aspect completely. It all came
down to this line :).
I collect this stuff I do for blog posts. But I need to find a native
english speaker with a tapestry background first :).
2013/10/17 Lance Java <la...@googlemail.com>
> It sounds like an interesting way to test. I'm guessing you can define your
> template directly in your test case rather than needing a separate file. If
> you were using groovy for testing this would be even nicer since you could
> use multi-line strings (via """). Or maybe you've come up with some cool
> way to generate a template given a component class and a map of parameters?
> I'd like to see a blog post ;)
>
> If you re-use the registry and have hundreds of tests, you might need to
> avoid the cache in DynamicTemplateParser by calling the following directly:
> new DynamicTemplateSaxParser(resource, bindingSource,
> componentTemplateParser.getDTDURLMappings()).parse()
>
> Cheers,
> Lance.
>
Re: Dynamic Loading of Templates
Posted by Lance Java <la...@googlemail.com>.
It sounds like an interesting way to test. I'm guessing you can define your
template directly in your test case rather than needing a separate file. If
you were using groovy for testing this would be even nicer since you could
use multi-line strings (via """). Or maybe you've come up with some cool
way to generate a template given a component class and a map of parameters?
I'd like to see a blog post ;)
If you re-use the registry and have hundreds of tests, you might need to
avoid the cache in DynamicTemplateParser by calling the following directly:
new DynamicTemplateSaxParser(resource, bindingSource,
componentTemplateParser.getDTDURLMappings()).parse()
Cheers,
Lance.
Re: Dynamic Loading of Templates
Posted by Martin Kersten <ma...@gmail.com>.
Lance it works. I can render any string given as a template. All I ever
wanted. Same should be true for components also.
Cheers,
Martin (Kersten)
2013/10/15 Martin Kersten <ma...@gmail.com>
> I dont want to cache it actually I will dig into it today to see if this
> becomes a problem. My Goal is to provide a string and let it be parsed as
> template. Therefore every test case can have its own 'template' for the
> same page. This way I could set up the component environment to test it
> easily.
>
> I will report back my findings.
>
>
> 2013/10/15 Lance Java <la...@googlemail.com>
>
>> I'm interested to see if it works. It's worth noting that your Resource
>> implementation should have a proper hashCode() and equals() to take
>> advantage of template caching.
>>
>
>
Re: Dynamic Loading of Templates
Posted by Martin Kersten <ma...@gmail.com>.
I dont want to cache it actually I will dig into it today to see if this
becomes a problem. My Goal is to provide a string and let it be parsed as
template. Therefore every test case can have its own 'template' for the
same page. This way I could set up the component environment to test it
easily.
I will report back my findings.
2013/10/15 Lance Java <la...@googlemail.com>
> I'm interested to see if it works. It's worth noting that your Resource
> implementation should have a proper hashCode() and equals() to take
> advantage of template caching.
>
Re: Dynamic Loading of Templates
Posted by Lance Java <la...@googlemail.com>.
I'm interested to see if it works. It's worth noting that your Resource
implementation should have a proper hashCode() and equals() to take
advantage of template caching.
Re: Dynamic Loading of Templates
Posted by Martin Kersten <ma...@gmail.com>.
Well thats one way but I thought about doing it the same way issuing a
render command omitting the need of a component. I will give it a try.
2013/10/14 Lance Java <la...@googlemail.com>
> I've never used it myself but I assume it'd be something like:
>
> Java
> -----
> public class MyDynamicPage {
> @Inject
> private DynamicTemplateParser parser;
>
> @Property
> private DynamicTemplate template;
> public void onActivate(EventContext context) {
> // TODO: implement this
> Resource templateResource = generateTemplateResource(context);
>
> template = parser.parseTemplate(templateResource);
> }
> }
>
> TML
> -----
> <t:dynamic template="prop:template" />
>
Re: Dynamic Loading of Templates
Posted by Lance Java <la...@googlemail.com>.
I've never used it myself but I assume it'd be something like:
Java
-----
public class MyDynamicPage {
@Inject
private DynamicTemplateParser parser;
@Property
private DynamicTemplate template;
public void onActivate(EventContext context) {
// TODO: implement this
Resource templateResource = generateTemplateResource(context);
template = parser.parseTemplate(templateResource);
}
}
TML
-----
<t:dynamic template="prop:template" />