>
> 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 <thiag...@gmail.com>
> On Fri, 18 Oct 2013 13:51:56 -0300, Martin Kersten <
> martin.kersten...@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<users-unsubscr...@tapestry.apache.org>
>
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
