>
> 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.
Do
On Fri, 18 Oct 2013 13:51:56 -0300, Martin Kersten
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 dynam
> 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
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 in
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
On Thu, 17 Oct 2013 11:17:26 -0300, Martin Kersten
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
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
> It sounds like an interesting way to test. I'm gue
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
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
> 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
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'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.
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
> I've never used it myself but I assume it'd be something like:
>
> Java
> -
> public class MyDynamicPage {
>@Inject
>
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
Resour
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 p
14 matches
Mail list logo
