I added comments to 2099 and 2327 but I don't think I can update the
version. Both are easy to fix and I included suggestions for fixing them
On Monday, February 22, 2016, Jochen Kemnade
wrote:
> Am 22.02.2016 um 13:40 schrieb Bob Harner:
>
>> I think a high percentage of those issues do affect
I've run into this problem with the hibernate config file see
https://community.jboss.org/wiki/HibernateCoreMigrationGuide36
The namespace has changed to
http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd
On Fri, Feb 7, 2014 at 2:54 PM, Howard Lewis Ship wrote:
> :tapestry-hibernat
Not really the same problem but I also found Hibernate 4 does not work with
some earlier versions of Tomcat. Hibernate reports it cannot find the JNDI
database even though it is there. This appears to be a Tomcat problem and I
fixed it by upgrading to Tomcat 7.0.50.
On Thu, Feb 6, 2014 at 8:46 AM
When I first wrote the tapestry-bootstrap module someone on the list
pestered me (thanks) to make it backward compatible with the current
components so you could have both Bootstrap and the older Tapestry
components on the same page. After some tinkering I discovered it was for
the most part possib
passing null for the annotation provider results in a null pointer
exception in 5.4
On Mon, Oct 14, 2013 at 9:06 AM, Thiago H de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Mon, 14 Oct 2013 09:56:05 -0300, Barry Books wrote:
>
> found NullAnnotaionProvider which is
found NullAnnotaionProvider which is somewhat better
invoice = provider.provide(Invoice.*class*, *new* NullAnnotationProvider(),
*null*, *true*);
On Mon, Oct 14, 2013 at 7:45 AM, Barry Books wrote:
> finally got around to this and it does not work in
thiag...@gmail.com> wrote:
> On Mon, 30 Sep 2013 09:50:14 -0300, Barry Books wrote:
>
> Thanks for the example. I think that will meet my needs.
>>
>
> Yay! :)
>
>
> I don't think I
>> would have ever figured that out from the existing documentation.
>
e hosted. It is based on Google code IIRC.
>
> Uli
>
> On 2013-10-09 12:50, Barry Books wrote:
> > Lenny I agree with some of what you say and I have a few comments because
> > I've been thinking about this also. I don't really have a problem with 3
> > CDI imp
;
> BTW, I am also of the idea that, no matter its implementation, such kind
> of things should not be hosted on Apache premises
>
>
> -- Alessio
>
> On 9-ott-2013, at 12:50, Barry Books wrote:
>
> > Lenny I agree with some of what you say and I have a few comments be
Lenny I agree with some of what you say and I have a few comments because
I've been thinking about this also. I don't really have a problem with 3
CDI implementations but I don't think I could find any of them. I think
there needs to be some repository of 3rd party modules and I don't think
the apa
Thanks for the example. I think that will meet my needs. I don't think I
would have ever figured that out from the existing documentation.
On Mon, Sep 30, 2013 at 6:21 AM, Thiago H de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Sat, 28 Sep 2013 11:20:21 -0300, Barry Books
ice that does this out of the
box.
I think in order to build a set of Modules that cooperate thru Interfaces
there needs to be a common way to instantiate real classes from Interfaces.
On Fri, Sep 27, 2013 at 7:05 PM, Thiago H de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Fri,
ally good about using Interfaces to define functionality
but it's difficult to do this in modules that define components. This
solves most of the problems.
On Fri, Sep 27, 2013 at 3:49 PM, Thiago H de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Fri, 27 Sep 2013 16:39:14 -030
Class, Map) already does in the sense that you want
> to associate certain objets to a given class (the config field in
> ObjectFactoryImpl)?
>
>
> On Fri, 27 Sep 2013 15:32:00 -0300, Barry Books wrote:
>
> I created a pretty simple service that's proven quite use
I created a pretty simple service that's proven quite useful. The interface
is
*public* *interface* ObjectFactory {
*public* T build(Class clazz);
}
it's built on top of autobuild and since it's a service you can plug in
different factories. The one I have this
*public* *class* ObjectFact
fest rather than Tapestry reading it.
>
>
> On Wed, Sep 25, 2013 at 6:03 AM, Barry Books >
> wrote:
>
> > I had a module class with a package name the resulted in a class path of
> > more than 72 characters. Apparently the Manifest spec says this:
> >
> > Name-V
I had a module class with a package name the resulted in a class path of
more than 72 characters. Apparently the Manifest spec says this:
Name-Value pairs and SectionsBefore we go to the details of the contents of
the individual configuration files, some format convention needs to be
defined. In m
ve to be in
> the same relative path.
> Also, Tapestry has some nice things like forever-caching etc. that I like
> to take advantage of
>
> On Sep 24, 2013, at 8:49 AM, Barry Books wrote:
>
> > I could go either way on this but I can see why you want to turn this
> off.
&
I could go either way on this but I can see why you want to turn this off.
FYI I don't deploy my GWT client code thru Tapestry at all. Is there any
reason why you do?
On Tue, Sep 24, 2013 at 7:33 AM, Thiago H de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Mon, 23 Sep 2013 21:43:55 -0300,
ap and T5.4?
> And also is it in maven central yet?
>
>
>
> On Sep 18, 2013, at 7:53 PM, Barry Books wrote:
>
> > I was planing on using modernizr to detect if type="date" is supported.
> > I've also added min and max to the mixin since they are also suppo
I agree with Geoff. It's easy to include the core stack in a Layout
component.
On Wed, Sep 18, 2013 at 7:48 PM, Lenny Primak wrote:
> Technically I agree but it breaks compatibility. So I reluctantly disagree.
>
>
>
> On Sep 18, 2013, at 7:39 PM, Geoff Callender <
> geoff.callender.jumpst...@gma
e before
> deciding whether to display a JavaScript datepicker.
>
> Similarly, recent releases of Chrome handle type="date" with a pretty good
> picker, so maybe what's needed is a parameter to declare which browsers to
> NOT override with our picker.
>
>
>
> On
to do is try to write my own datepicker. We should use
> one of the public ally available ones, I,e, bootstrap of jquery UI one.
>
> On Sep 17, 2013, at 10:09 PM, Barry Books wrote:
>
> > This is high on my list also. I've spent today looking at datepickers and
> > co
This is high on my list also. I've spent today looking at datepickers and
concluded none of them are perfect and it may be best to just implement the
one you want and not bother with the Tapestry one. However I do think
the TypeCoercer
for String to DateFormat needs to be fixed. The current one doe
I use CKEditor and had the same problem. I was able to use Thiago's code
and got it working
On Mon, Sep 16, 2013 at 12:55 PM, Lenny Primak wrote:
> JIRA created: https://issues.apache.org/jira/browse/TAP5-2185
>
> On Sep 16, 2013, at 8:47 AM, Thiago H de Paula Figueiredo wrote:
>
> > On Mon, 16
ownloading a newer version of the
> >> resource when that is available at a later date.
> >>
> >>
> >>
> >> On Thu, Sep 12, 2013 at 7:57 AM, Thiago H de Paula Figueiredo <
> >> thiag...@gmail.com> wrote:
> >>
> >> On Thu, 12
ueiredo <
thiag...@gmail.com> wrote:
> On Wed, 11 Sep 2013 19:41:40 -0300, Barry Books wrote:
>
> Perhaps a dumb question but why does the checksum need to match for
>> Tapestry to return the file? The only problem I can think of is if the
>> included file changes but t
Perhaps a dumb question but why does the checksum need to match for
Tapestry to return the file? The only problem I can think of is if the
included file changes but the main file does not then the cached file might
be used. I would think that's unlikely to happen and could easily be solved
by just
True enough and to have any chance you are going to want something like
this:
configuration.add(JacquardConstants.XUACompatibleHeader,"IE=edge");
*public* *class* XUACompatibleHeader *implements* RequestFilter {
*private* *static* *final* String HEADER_KEY = "X-UA-Compatible";
*private* *fina
I have a few thoughts but they are conflicting.
1. Anything that makes testing easier would be welcome.
2. It would have to be beyond easy to create new test cases to make me want
to rewrite my old ones.
3. I'm sure (fill in you favorite language here) is great but I'm
mandated (It's more of a sug
at
> already
> > use Bootstrap, there are CSS adjustments for the particular version of
> > Bootstrap that Tapestry includes.
> >
> > I wonder if there is some mechanism that could be introduced that would
> > allow for the creation of compatibility modes (or co
If the goal if to have the browser cache the asset and only do a new
request when the asset changes I think the only reliable way to accomplish
this is by setting the expires header and changing the url when the asset
changes. This way the browser has no choice but to do the right thing.
What's th
>From the jQuery 2.0 release notes:
As promised, this version leaves behind the older Internet Explorer 6, 7,
> and 8 browsers. In return it is smaller, faster, and can be used in
> JavaScript environments where the code needed for old-IE compatibility
> often causes problems of its own. *But don’
heet.
>
>
> On Tue, Apr 9, 2013 at 6:26 AM, Barry Books wrote:
>
>> After being bitten by APPLICATION_VERSION I switched to this
>>
>> configuration.override(SymbolConstants.APPLICATION_VERSION,
>> *new*Date().getTime());
>>
>>
>> This wa
;
> See this:
> http://mail-archives.apache.org/mod_mbox/tapestry-users/201005.mbox/%3caanlktinz4ukjng-zom8t86ry-mrw7st7e9eufhkvv...@mail.gmail.com%3e
>
>
> On Tue, Apr 9, 2013 at 5:26 PM, Barry Books wrote:
>
>> After being bitten by APPLICATION_VERSION I switched t
nt.
>>
>> Also your clients will get new assets every time you restart your server.
>>
>> See this:
>>
>> http://mail-archives.apache.org/mod_mbox/tapestry-users/201005.mbox/%3caanlktinz4ukjng-zom8t86ry-mrw7st7e9eufhkvv...@mail.gmail.com%3e
>>
After being bitten by APPLICATION_VERSION I switched to this
configuration.override(SymbolConstants.APPLICATION_VERSION,
*new*Date().getTime());
This way on my development machine I get a new version every restart and on
my production machine on every deploy.
That said I think the hash of the
I agree it seems like the limitation was not intended and your suggestion is
best long term. Until then this part seemed the easiest to override.
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional comman
There have been several discussions on the user list about the failure
@BindParameter to override Parameters that have defaults set to
Symbols. The symbol bind prefix is readonly so attempting to override
the parameter value results in a read only exception. I've also run
into this issue and decide
I noticed Tapestry has a mixin called RenderInformals. I tried to use
it instead of the one I wrote and even though the code is the same it
did not work. I have a suspicion that it's really the mixin that sorts
first by name gets the informal parameters.
---
I was able to fix my specific problem but when I tried to do the same
thing on my test case the results are different.
I fixed my problem by creating another mixin with @MixinAfter that
renders informal parameters. My theory was that the first mixin to
render informal parameters gets the ones in t
I posted a question about @SupportsInformalParameters to the user list
yesterday but got no useful response. After writing some test cases
its clear to me @SupportsInformalParamters and mixins do not do what
the documentation says. My question is which is wrong the code or the
document?
>From the
I can see the overlap but I think the Metadata service is only for
pages/components and I was looking for a general purpose application
default solution. For example you could store the email address for
the site admin in here. I don't think the MetaData service would be
appropriate for that.
Perh
Sorry about the 2 part email.
The service to fetch the defaults is also pretty simple
https://github.com/trsvax/tapestry-trsvax/blob/master/src/test/java/com/trsvax/tapestry/misc/services/DefaultsImpl.java
So with these 3 parts you can do things like:
In a comonent
@Parameter(MyDefaults
I've been think about Howard's email a couple of days ago and it
occurred to me that while Tapestry provides a very good set of tools
for solving common problems encountered doing web development it does
not actually solve them. This is not a complaint and in fact I think
it's the right approach fo
MAKE IT EASIER TO DONATE COMPONENTS & CODE
I think this is a great idea but I don't think it needs to be that
complicated. To me the problem is there is no central repository for
module jars so I end up adding a bunch of repositories to my pom file.
All that's needed is a way to submit a reposito
I gave up trying to use the same page for create and edit because it
takes more code to use one page than two. My thought would be to do
this
@PageActivationContext(create=true)
private MyEntity myEntity;
This would create the object if you do not pass one in. Then you don't
have any backward com
I just spent about 30 minutes looking for a way to get the
ServletContext. I knew it was available but I could not remember which
service provides it. So while I was searching I was thinking it might
be nice to have a set of Interfaces/Services that define all the
public services. For Tapestry core
The zone parameter is easy to use but not very flexible. I wrote a
bind mixin for jQuery that hooks events to pretty much anything. I
suspect you could do the same thing in Prototype. Bind is subclassed
to the event you want to capture so multiple events can be attached to
a single element. Here is
49 matches
Mail list logo
