Nabble - My Faces - Dev

[jira] Commented: (TRINIDAD-799) Add agent version support in skinning

2008-05-13T10:23:55Z

[ https://issues.apache.org/jira/browse/TRINIDAD-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596463#action_12596463 ]

Blake Sullivan commented on TRINIDAD-799:
-----------------------------------------

If the current implementation doesn't match what was discussed, I believe that we should back it out and release. We can but the agreed upon api in the next release.

> Add agent version support in skinning
> -------------------------------------
>
> Key: TRINIDAD-799
> URL: https://issues.apache.org/jira/browse/TRINIDAD-799
> Project: MyFaces Trinidad
> Issue Type: Wish
> Components: Components
> Affects Versions: 1.0.4-core
> Reporter: Andrew Robinson
> Assignee: Andrew Robinson
> Fix For: 1.0.8-core, 1.2.8-core
>
>
> The current skinning functionality does not allow a skinning developer to differentiate between different browser versions. For example, it is possible to tell the difference between IE and firefox, but not between IE 6 and 7
> Possible implementations:
> 1) @agent ie6 { ... }
> 2) @agent ie { @agentVersion 6 { ... } }
> A more general and more powerful approach would be to allow developers to use a regex on the browser version:
> @agent match /MSIE [67]/

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-799) Add agent version support in skinning

2008-05-13T09:57:55Z

[ https://issues.apache.org/jira/browse/TRINIDAD-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596444#action_12596444 ]

Scott O'Bryan commented on TRINIDAD-799:
----------------------------------------

Thanks Andrew.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-799) Add agent version support in skinning

2008-05-13T09:55:55Z

[ https://issues.apache.org/jira/browse/TRINIDAD-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596442#action_12596442 ]

Scott O'Bryan commented on TRINIDAD-799:
----------------------------------------

As per this discussion: http://www.mail-archive.com/dev@.../msg32203.html, this bug is holding up the next Release of Trinidad.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-799) Add agent version support in skinning

2008-05-13T09:53:55Z

[ https://issues.apache.org/jira/browse/TRINIDAD-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596440#action_12596440 ]

Andrew Robinson commented on TRINIDAD-799:
------------------------------------------

Taking this over as it is holding up a release and we have had no response on the mailing list.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (TRINIDAD-799) Add agent version support in skinning

2008-05-13T09:43:55Z

[ https://issues.apache.org/jira/browse/TRINIDAD-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Robinson reopened TRINIDAD-799:
--------------------------------------

AFAIK the current implementation is not the one discussed as the desired implementation in the mailing list

> Add agent version support in skinning
> -------------------------------------
>
> Key: TRINIDAD-799
> URL: https://issues.apache.org/jira/browse/TRINIDAD-799
> Project: MyFaces Trinidad
> Issue Type: Wish
> Components: Components
> Affects Versions: 1.0.4-core
> Reporter: Andrew Robinson
> Assignee: Cristi Toth
> Fix For: 1.0.8-core, 1.2.8-core
>
>
> The current skinning functionality does not allow a skinning developer to differentiate between different browser versions. For example, it is possible to tell the difference between IE and firefox, but not between IE 6 and 7
> Possible implementations:
> 1) @agent ie6 { ... }
> 2) @agent ie { @agentVersion 6 { ... } }
> A more general and more powerful approach would be to allow developers to use a regex on the browser version:
> @agent match /MSIE [67]/

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: myfaces groovy support

2008-05-13T08:53:14Z

Andrew Robinson schrieb:
> Out of curiosity, will this be able to be extensible to support Jython
> as well? (some ppl like me prefer the jython syntax over groovy's)
>
Well it depends, if jython can generate java Classes through its Eval
functionality in the scripting adapter, then in the long run if someone
does it, yes.

Otherwise it might be hard.

The thing is I intercept a classloader which has to return a class
implementing the bean or jsf artefact the rest is infrastructure which
can be adapted easily to other scripting languages.
The classloader is necessary due to the fact that the scripts themselves
have to be loaded from somewhere, I am not sure if I can remove the
classloader at all, I don´t think so without any significant changes to
the core codebase.

Werner

Btw. Status: following artefacts are already kickstarting:
Beans,
PhaseListener,
ViewHandler

Re: myfaces groovy support

2008-05-13T08:26:13Z

Out of curiosity, will this be able to be extensible to support Jython
as well? (some ppl like me prefer the jython syntax over groovy's)

On Mon, May 12, 2008 at 11:45 PM, Werner Punz <werner.punz@...> wrote:

> Hello everyone
>
> I just wanted to give notification that I took a small break from my
> components project which is still on track and that I am working on myfaces
> groovy support.
>
> I got the first artefacts already reloading, and a first code will
> be made available by the end of the week, early next week.
>
> (For the Sun guys reading, thanks a lot you gave me the final push to do
> it, although I did many things differently than you did)
>
> Ok what will be done:
> First of all I replaced all the factories with my own ones
> to enable the entire system, I also had to write my own context listener
> to handle the classloader issues.
> (We really need a change in the spec here to enable scripting properly -
> Ed?)
>
>
> Secondly once the factories were in place I added proxy generation code
> wherever needed to enable reloading proxies.
>
>
> Third, a classloader which forks into the groovy system to load the groovy
> code.
> The groovy code also has its own reloading weaving code added to enable
> reloading of groovy files on the groovy side of things (the woven aop
> reloading code is lost on the java side however if you just deliver classes
> instead of objects, my first approach was a try to enable everything on the
> java side)
>
> So what do we get
> Reloading for most artefacts (probably on method level if things work out
> the way I intend them to be (For certain artefacts
> there are contracts you have to program in on the groovy side to enable
> this - aka expose the private properties some artefacts have otherwise
> a on method reloading will not be possible).
>
> Maybe and this is a big maybe, if I can get it up and running (I want to
> replace code on the fly) reloading of methods on groovy classes loaded by
> groovy over the new classloader.
> Again this is a big if, I have not prototyped this fully yet, but it should
> be possible.
> The idea is, once you load an in groovy object over the classloader
> it should be possible to change its methods on the fly via the meta
> programming capabilities of groovy.
>
> Ok first code around friday or early next week. After that I will start
> further discussions.
>
> And again, thanks to Ryan and Ed for finally pushing me towards it
> (indirectly by doing it).
>
> I also have to admit I have had a look at some parts of the code to check
> how you guys solved some problems I have been facing - especially the
> dreaded classloader issues and weaving issues.
> (I did most of the stuff differently though due to the different approach I
> am doing, of a mixed groovy/java infrastructure to enable some things not
> reachable from the java side that easily, also I did not want to change the
> core code, I wanted to have it more as an extension).
>
> If you want to have a look at the code upfront
> before next week, send me a private mail, I just do not want to post
> it yet because it still is not done enough for a public post.
> Especially the init code I am still very unhappy with.
>
>
>
> Werner
>
>

[jira] Updated: (TOMAHAWK-1084) amISpannedOver doesn't ignore non-rendered columns

2008-05-13T05:46:55Z

[ https://issues.apache.org/jira/browse/TOMAHAWK-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Zwink updated TOMAHAWK-1084:
-----------------------------------

Status: Patch Available (was: Open)

> amISpannedOver doesn't ignore non-rendered columns
> --------------------------------------------------
>
> Key: TOMAHAWK-1084
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1084
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: Extended Datatable
> Affects Versions: 1.1.5
> Reporter: Paul Pogonyshev
> Priority: Minor
>
> In data table renderer there is amISpannedOver() method. It seems to work fine except that it doesn't ignore non-rendered columns.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-1070) lightwight dialog autoresize does not work correctly

2008-05-13T03:10:55Z

[ https://issues.apache.org/jira/browse/TRINIDAD-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mathias Walter updated TRINIDAD-1070:
-------------------------------------

Status: Patch Available (was: Open)

> lightwight dialog autoresize does not work correctly
> ----------------------------------------------------
>
> Key: TRINIDAD-1070
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1070
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 1.2.7-core
> Environment: Tomcat 6.0.14, Sun JSF RI 1.2, Windows XP SP2, FireFox 2.0.14, FireFox 3.0b5, IE6, Facelets 1.1.14
> Reporter: Mathias Walter
> Attachments: lwdlg_correctwidth_IE.jpg, lwdlg_wrongwidth_FF_1.jpg, lwdlg_wrongwidth_FF_2.jpg
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> A simple lightweight dialog does not get shown correctly in FireFox (see screenshots). The width is not set correctly to the content width and therefore a horizontal scroll bar is shown. The reason is maybe a large combobox.
> Code:
> <?xml version='1.0' encoding='utf-8'?>
> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:f="http://java.sun.com/jsf/core"
> xmlns:tr="http://myfaces.apache.org/trinidad" xmlns:trh="http://myfaces.apache.org/trinidad/html"
> xmlns:h="http://java.sun.com/jsf/html"
> version="1.2">
> <trh:head>
> <title>Arzt auswählen</title>
> </trh:head>
> <trh:body>
> <tr:form>
> <tr:panelFormLayout>
> <tr:selectOneChoice label="Arzt:" value="#{physicians.choosed}" required="true">
> <f:selectItems value="#{physicians.items}" />
> </tr:selectOneChoice>
> </tr:panelFormLayout>
> <tr:separator />
> <tr:panelButtonBar halign="center">
> <tr:commandButton id="save" action="#{physicians.select}" text="Übernehmen" />
> <tr:commandButton id="cancel" action="#{physicians.cancelSelect}" text="Abbrechen" immediate="true" />
> </tr:panelButtonBar>
> </tr:form>
> </trh:body>
> </html>

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-1070) lightwight dialog autoresize does not work correctly

2008-05-13T03:10:55Z

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-1068) ID not unique in generated html of tableheader (duplicate id detailStamp)

2008-05-13T03:08:55Z

[ https://issues.apache.org/jira/browse/TRINIDAD-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mathias Walter updated TRINIDAD-1068:
-------------------------------------

Status: Patch Available (was: Open)

> ID not unique in generated html of tableheader (duplicate id detailStamp)
> -------------------------------------------------------------------------
>
> Key: TRINIDAD-1068
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1068
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
> Affects Versions: 1.2.6-core, 1.2.7-core
> Reporter: martin piekorz
>
> If I place two tables in one page, the id of the generated table header for the selection row is in both tables unique.
> All other table head ids are unique.
> <table_one ....
> <th id="j_id8"...
> ...
> <table_two ...
> <th id="j_id8"
> ...
> 08.05.2008 16:37:41 org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId
> WARNUNG: The id "j_id8" is used more than once.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: myfaces groovy support

2008-05-13T00:29:38Z

Unfortunately I did an accidental post of this
in the RI devs mailinglist
speaking of being chaotic and early morning.

:-(

Werner

Manfred Geiler schrieb:

> Cool thing, Werner. Congrats!
> --Manfred
>
> On Tue, May 13, 2008 at 7:45 AM, Werner Punz <werner.punz@...> wrote:
>> Hello everyone
>>
>> I just wanted to give notification that I took a small break from my
>> components project which is still on track and that I am working on myfaces
>> groovy support.
>>
>> I got the first artefacts already reloading, and a first code will
>> be made available by the end of the week, early next week.
>>
>> (For the Sun guys reading, thanks a lot you gave me the final push to do
>> it, although I did many things differently than you did)
>>
>> Ok what will be done:
>> First of all I replaced all the factories with my own ones
>> to enable the entire system, I also had to write my own context listener
>> to handle the classloader issues.
>> (We really need a change in the spec here to enable scripting properly -
>> Ed?)
>>
>>
>> Secondly once the factories were in place I added proxy generation code
>> wherever needed to enable reloading proxies.
>>
>>
>> Third, a classloader which forks into the groovy system to load the groovy
>> code.
>> The groovy code also has its own reloading weaving code added to enable
>> reloading of groovy files on the groovy side of things (the woven aop
>> reloading code is lost on the java side however if you just deliver classes
>> instead of objects, my first approach was a try to enable everything on the
>> java side)
>>
>> So what do we get
>> Reloading for most artefacts (probably on method level if things work out
>> the way I intend them to be (For certain artefacts
>> there are contracts you have to program in on the groovy side to enable
>> this - aka expose the private properties some artefacts have otherwise
>> a on method reloading will not be possible).
>>
>> Maybe and this is a big maybe, if I can get it up and running (I want to
>> replace code on the fly) reloading of methods on groovy classes loaded by
>> groovy over the new classloader.
>> Again this is a big if, I have not prototyped this fully yet, but it should
>> be possible.
>> The idea is, once you load an in groovy object over the classloader
>> it should be possible to change its methods on the fly via the meta
>> programming capabilities of groovy.
>>
>> Ok first code around friday or early next week. After that I will start
>> further discussions.
>>
>> And again, thanks to Ryan and Ed for finally pushing me towards it
>> (indirectly by doing it).
>>
>> I also have to admit I have had a look at some parts of the code to check
>> how you guys solved some problems I have been facing - especially the
>> dreaded classloader issues and weaving issues.
>> (I did most of the stuff differently though due to the different approach I
>> am doing, of a mixed groovy/java infrastructure to enable some things not
>> reachable from the java side that easily, also I did not want to change the
>> core code, I wanted to have it more as an extension).
>>
>> If you want to have a look at the code upfront
>> before next week, send me a private mail, I just do not want to post
>> it yet because it still is not done enough for a public post.
>> Especially the init code I am still very unhappy with.
>>
>>
>>
>> Werner
>>
>>
>
>
>

[jira] Commented: (TRINIDAD-1070) lightwight dialog autoresize does not work correctly

2008-05-13T00:10:55Z

[ https://issues.apache.org/jira/browse/TRINIDAD-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596307#action_12596307 ]

Mathias Walter commented on TRINIDAD-1070:
------------------------------------------

I've also tried to use '<html jsfc="trh:html">', but it doesn't help either.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: myfaces groovy support

2008-05-12T23:54:57Z

Cool thing, Werner. Congrats!
--Manfred

On Tue, May 13, 2008 at 7:45 AM, Werner Punz <werner.punz@...> wrote:

--
http://www.irian.at
Your JSF powerhouse - JSF Consulting,
Development and Courses in English and
German

Professional Support for Apache MyFaces

myfaces groovy support

2008-05-12T22:45:57Z

Hello everyone

I just wanted to give notification that I took a small break from my
components project which is still on track and that I am working on
myfaces groovy support.

I got the first artefacts already reloading, and a first code will
be made available by the end of the week, early next week.

(For the Sun guys reading, thanks a lot you gave me the final push to do
it, although I did many things differently than you did)

Ok what will be done:
First of all I replaced all the factories with my own ones
to enable the entire system, I also had to write my own context listener
to handle the classloader issues.
(We really need a change in the spec here to enable scripting properly -
Ed?)

Secondly once the factories were in place I added proxy generation code
wherever needed to enable reloading proxies.

Third, a classloader which forks into the groovy system to load the
groovy code.
The groovy code also has its own reloading weaving code added to enable
reloading of groovy files on the groovy side of things (the woven aop
reloading code is lost on the java side however if you just deliver
classes instead of objects, my first approach was a try to enable
everything on the java side)

So what do we get
Reloading for most artefacts (probably on method level if things work
out the way I intend them to be (For certain artefacts
there are contracts you have to program in on the groovy side to enable
this - aka expose the private properties some artefacts have otherwise
a on method reloading will not be possible).

Maybe and this is a big maybe, if I can get it up and running (I want to
replace code on the fly) reloading of methods on groovy classes loaded
by groovy over the new classloader.
Again this is a big if, I have not prototyped this fully yet, but it
should be possible.
The idea is, once you load an in groovy object over the classloader
it should be possible to change its methods on the fly via the meta
programming capabilities of groovy.

Ok first code around friday or early next week. After that I will start
further discussions.

And again, thanks to Ryan and Ed for finally pushing me towards it
(indirectly by doing it).

I also have to admit I have had a look at some parts of the code to
check how you guys solved some problems I have been facing - especially
the dreaded classloader issues and weaving issues.
(I did most of the stuff differently though due to the different
approach I am doing, of a mixed groovy/java infrastructure to enable
some things not reachable from the java side that easily, also I did not
want to change the core code, I wanted to have it more as an extension).

If you want to have a look at the code upfront
before next week, send me a private mail, I just do not want to post
it yet because it still is not done enough for a public post.
Especially the init code I am still very unhappy with.

Werner

Re: new name for sev-en

2008-05-12T16:47:09Z

I do like Jack.... We could write a usage tutorial called: "You don't
know Jack"..

Scott

Matthias Wessendorf wrote:

> I'd prefer a Spanish word...
> To me checker sounds stupid.
> (krasser checker...)
>
> -M
>
> Sent from my iPod.
>
> Am 11.05.2008 um 01:55 schrieb "Gerhard Petracek"
> <gerhard.petracek@... <mailto:gerhard.petracek@...>>:
>
>> @andrew:
>> it depends on the mother tongue. ;)
>> for some of you 'seven' sounds boring - especially if english is your
>> mother tongue.
>> words of foreign languages sound much more interesting.
>> if i translate 'seven' into my mother tongue, it also sounds a bit
>> boring (just because it isn't exotic for me).
>> in my country it's a kind of "trend" to use english words.
>>
>> so maybe we should just use an "invented" name or an acronym.
>> e.g.:
>> jac (_j_ava _a_nnotation _c_hecker)
>> jack (_j_ava _a_nnotation _c_hec_k_er)
>>
>> if you translate e.g. 'jack' into my mother tongue, there are a lot
>> of different meanings.
>> so there is no real meaning - it just sounds interesting (it's a
>> matter of taste).
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2008/5/10 Leonardo Uribe <lu4242@... <mailto:lu4242@...>>:
>>
>> Some spanish words:
>>
>> myfaces-commons-validacion
>> myfaces-commons-validar
>> myfaces-commons-validador
>> myfaces-commons-valide
>> myfaces-commons-evaluador
>>
>>
>> On Sat, May 10, 2008 at 3:12 PM, Hazem Saleh
>> <hazem.saleh@... <mailto:hazem.saleh@...>> wrote:
>>
>> +1 for myfaces-commons-checker.
>>
>>
>> On Sat, May 10, 2008 at 1:53 PM, Gerhard Petracek
>> <gerhard.petracek@...
>> <mailto:gerhard.petracek@...>> wrote:
>>
>> do you have a further suggestion?
>> maybe a bit more fancy?
>>
>> e.g. one of the suggestions i heard is:
>> myfaces-commons-checker
>>
>> maybe it's a new starting point for further suggestions.
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2008/4/29 Scott O'Bryan <darkarena@...
>> <mailto:darkarena@...>>:
>>
>> How about "convalidi". It's validate in Italian (I
>> think).
>>
>> Gerhard Petracek wrote:
>>
>> hello scott,
>>
>> do you have a suggestion for a short and fancy name?
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2008/4/27 Scott O'Bryan <darkarena@...
>> <mailto:darkarena@...>
>> <mailto:darkarena@...
>> <mailto:darkarena@...>>>:
>>
>>
>> +1 to not naming it validations. There is
>> already a commons
>> validator.
>>
>> -0 to including core in the name
>>
>> Strong -1 to including JSR in the project
>> name. A jar is nearly
>> an enhancement number for java. You wouln't
>> name your project
>> something like MyFaces-1234 after a Jira
>> ticket number.
>>
>>
>> On Apr 26, 2008, at 10:25 AM, "Gerhard Petracek"
>> <gerhard.petracek@...
>> <mailto:gerhard.petracek@...>
>> <mailto:gerhard.petracek@...
>> <mailto:gerhard.petracek@...>>>
>> wrote:
>>
>> hello alexander,
>>
>> i got your idea.
>> however, i hope we will find a short and
>> fancy name.
>>
>> if we don't have 'core' within the name, i
>> think we have to find
>> something else than just 'validation'.
>> otherwise it will be a bit confusing for
>> users due to the fact
>> that the core itself doesn't validate.
>> concrete validation logic is located
>> within the
>> independent/optional modules.
>> the target is to have a core which
>> provides the infrastructure
>> and which encapsulates the specifics of
>> the jsf version.
>> furthermore, the core is independent of
>> specific annotations. the
>> optional modules provide the concrete
>> annotations and/or
>> validation logic (independent of the jsf
>> version).
>> (reason for and/or: we don't provide the
>> annotations of jpa nor
>> of jsr 303 - we just provide the
>> validation strategies for these
>> external annotations.)
>>
>> @myfaces-commons-validation-annotations:
>> it isn't a pure annotation module - it
>> also provides the
>> validation strategies and much more.
>> (in the case of the jpa validation support
>> it just provides the
>> validation strategy.)
>> moreover, i would suggest that we rename
>> seven-validation to
>> seven-ext-validation or a bit shorter:
>> seven-extval (for extended
>> validation)
>> or something similar which indicates that
>> these are our
>> annotations (and so on).
>>
>> @myfaces-commons-validation-jsr303:
>> i'm fine with both jsr303 (my original
>> suggestion) or bean-validation
>>
>> the names of our compromise so far:
>>
>> myfaces-commons-[new name]
>> (= the core)
>>
>> myfaces-commons-[new name]-validation
>> (= our annotations + validation strategies
>> incl. cross-component
>> validation infrastructure and also the jpa
>> validation strategy,...)
>>
>> myfaces-commons-[new name]-bean-validation
>> (= the infrastructure and validation
>> strategies to support jsr 303)
>>
>> fancy suggestions for [new name] are welcome.
>> (we need some suggestions to open a vote.)
>>
>> or what's about something different
>> it isn't my favourite - however, it might
>> be an impulse for other
>> suggestions.
>>
>> e.g.:
>> myfaces-commons-validation-core
>> myfaces-commons-validation-extval
>> myfaces-commons-validation-jsr303 (or
>> bean-validation)
>>
>> (i prefer an independent name.)
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2008/4/25 Jesse Alexander (KSFH 336)
>> <alexander.jesse@...
>> <mailto:alexander.jesse@...>
>> <mailto:alexander.jesse@...
>> <mailto:alexander.jesse@...>>>:
>>
>>
>>
>> we are getting side-tracked...
>> let's find a name within this
>> thread! :)
>>
>> validation ?
>> ->
>> myfaces-commons-validation
>> myfaces-commons-validation-annotations
>> (was -validation)
>> myfaces-commons-validation-jsr303
>> (was bean-validation)
>> kind regards
>> Alexander
>>
>>
>>
>>
>> --
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>>
>>
>>
>>
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>>
>>
>>
>>
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>>
>>
>>
>> --
>> Hazem Ahmed Saleh Ahmed
>> http://www.jroller.com/page/HazemBlog
>>
>>
>>
>>
>>
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces

Re: [trinidad] release? I need help...

2008-05-12T16:40:34Z

Hey Cristi,

What is the status of Trinidad-799? Is it checked in and ready to go.
If so I'm going to start the release process.

Scott

Cristi Toth wrote:

>
> On Mon, May 5, 2008 at 11:00 PM, Scott O'Bryan <darkarena@...
> <mailto:darkarena@...>> wrote:
>
> Easy enough for me since I'm in the middle of something else right
> now.. Cristi, can you ping me on this thread when TRINIDAD-799 is
> done and committed? I'll try to monitor it, but just in case I
> miss it... :)
>
>
> I'll try not to forget ;)
>
>
>
> Andrew Robinson wrote:
>
> +1 for the release to wait on TRINIDAD-799
>
> On Mon, May 5, 2008 at 2:32 PM, Cristi Toth
> <cristi.toth@... <mailto:cristi.toth@...>> wrote:
>
>
> Hey guys...
>
> There is an issue still opened reagarding TRINIDAD-799
> I resolved it, but the guys here didn't agree with the
> "api" and also
> changed the requirements.
>
> There was a long discussion about this and it seemed it
> reached an agreement
> about the "api",
> but I need some code for determining the agent minor version.
> Blake said there is something like this in Rich Client
> already and that you
> could donate the regex used for that.
> But since then he didn't give any sign of the code and I
> had no time to bug
> him with that.
>
> When do you plan to freeze and prepare the release?
> It would be a nice feature to have in this new release.
>
> cheers
>
>
>
> On Mon, May 5, 2008 at 9:44 PM, Scott O'Bryan
> <darkarena@... <mailto:darkarena@...>> wrote:
>
>
>
> Hey Matthias, I think I can jump in later today or
> early tomorrow if you
>
>
> havn't got anyone yet.
>
>
> Scott
>
>
>
>
> Matthias Wessendorf wrote:
>
>
>
> Http://myfaces.apache.org/trinidad
>
> Sent from my iPod.
>
> Am 05.05.2008 um 21:10 schrieb "Nutulapati, Krishna"
>
>
> <KNutulapati@... <mailto:KNutulapati@...>>:
>
>
>
>
> Can you give me the link from where I can
> download new version of
> trinidad?
> Thanks
> Krishna
>
> -----Original Message-----
> From: Matthias Wessendorf
> [mailto:mwessendorf@...
> <mailto:mwessendorf@...>]
> Sent: Monday, May 05, 2008 2:01 PM
> To: MyFaces Development
> Subject: [trinidad] release? I need help...
>
> Hello,
>
> I think it is time for a new trinidad release.
> However i am currently
> not able to manage that, because I broke my
> right arm.
>
> Would be cool if someone could jump in.
>
> Thanks,
> Matthias
>
> Sent from my iPod.
>
>
>
>
>
>
> --
> Cristi Toth
>
> -------------
> Codebeat
> www.codebeat.ro <http://www.codebeat.ro>
>
>
>
>
>
>
> --
> Cristi Toth
>
> -------------
> Codebeat
> www.codebeat.ro <http://www.codebeat.ro>

[jira] Created: (TRINIDAD-1073) Character encoding problem with PPR on IBM WebSphere 6.0

2008-05-12T15:56:55Z

Character encoding problem with PPR on IBM WebSphere 6.0
--------------------------------------------------------

Key: TRINIDAD-1073
URL: https://issues.apache.org/jira/browse/TRINIDAD-1073
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.0.7-core
Environment: MyFaces 1.1.5
IBM WebSphere 6.0
Windows XP SP2
Reporter: Vadim Dmitriev

Input fields updated via PPR replace cyrillic characters with question marks. There is no encoding problems if update is performed with ordinary form submit.

Simple testcase:
create JSF page with tr:showDetailHeader containing tr:inputText. Type some cyrillic characters in the input field. Close/open detailheader. As a result cyrillic chars in the inputText will be replaced with question marks.
There is no problem with encoding whatsoever if that showDetailHeader is updated by ordinary update (navigation from/to that page, for example).

This problem is specific to WebSphere 6.0 (maybe 6.1 too, never had a chance to check it). I tried the same testcase on OC4J 10.3.3.2 and everything went fine.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TOBAGO-665) Move onComponentCreated to Renderer

2008-05-12T12:36:55Z

Move onComponentCreated to Renderer
-----------------------------------

Key: TOBAGO-665
URL: https://issues.apache.org/jira/browse/TOBAGO-665
Project: MyFaces Tobago
Issue Type: Improvement
Components: Core, Themes
Reporter: Bernd Bohmann
Assignee: Bernd Bohmann
Fix For: 1.1.0

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TOBAGO-664) Avoid buffering of the request or request parts as much as possible

2008-05-12T12:28:55Z

Avoid buffering of the request or request parts as much as possible
-------------------------------------------------------------------

Key: TOBAGO-664
URL: https://issues.apache.org/jira/browse/TOBAGO-664
Project: MyFaces Tobago
Issue Type: Improvement
Components: Core, Themes
Reporter: Bernd Bohmann
Assignee: Bernd Bohmann
Fix For: 1.1.0

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [TRINIDAD] Type-o on web site navigation panel (site.xml)

2008-05-12T08:20:01Z

Thanks, fixed it.

-A

On Mon, May 12, 2008 at 7:59 AM, Paul Spencer <paulsp@...> wrote:
> The work "Overview" is misspelled in
> /myfaces/trinidad/trunk/src/site/site.xml. It is currently on the page as
> "Overwie"
>
> Paul Spencer
>

[TRINIDAD] Type-o on web site navigation panel (site.xml)

2008-05-12T06:59:38Z

The work "Overview" is misspelled in
/myfaces/trinidad/trunk/src/site/site.xml. It is currently on the page
as "Overwie"

Paul Spencer

[jira] Resolved: (TOBAGO-646) Allow to configure an unsorted image for sorted columns in the sheet

2008-05-12T03:15:55Z

[ https://issues.apache.org/jira/browse/TOBAGO-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bernd Bohmann resolved TOBAGO-646.
----------------------------------

Resolution: Fixed

> Allow to configure an unsorted image for sorted columns in the sheet
> --------------------------------------------------------------------
>
> Key: TOBAGO-646
> URL: https://issues.apache.org/jira/browse/TOBAGO-646
> Project: MyFaces Tobago
> Issue Type: Improvement
> Components: Themes
> Affects Versions: 1.0.16
> Reporter: Bernd Bohmann
> Assignee: Bernd Bohmann
> Priority: Minor
> Fix For: 1.0.17, 1.1.0
>
>

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TOBAGO-662) Use LOG.isInfoEnabled() for LOG.info()

2008-05-12T03:15:55Z

[ https://issues.apache.org/jira/browse/TOBAGO-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bernd Bohmann resolved TOBAGO-662.
----------------------------------

Resolution: Fixed

> Use LOG.isInfoEnabled() for LOG.info()
> --------------------------------------
>
> Key: TOBAGO-662
> URL: https://issues.apache.org/jira/browse/TOBAGO-662
> Project: MyFaces Tobago
> Issue Type: Improvement
> Affects Versions: 1.0.16
> Reporter: Bernd Bohmann
> Assignee: Bernd Bohmann
> Fix For: 1.0.17, 1.1.0
>
>

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.