Sure, I was looking for a jira issue dealing with this problem before
my commit last night, but I could not find one. Next time I will open
a new one ;)
On 8/25/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
Also, and I know this isn't always possible, could you commit your
code cleanup separ
yeah,
same here :(
anyone listening ?
On 8/24/06, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
Hello,
can somebody kill the processid 19259 and restart continuum? I think
continuum is not running and i can't really stop it.
Regards
Bernd
--
Matthias Wessendorf
further stuff:
blog: http://j
On 8/23/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
Ok, but that's a far cry from Matze's "for all commits". For all major
enhancements, I'm absolutely d'accord.
I'd be thrilled to have every commit reference a JIRA issue, but
that's probably too much to ask all at once. For now I'll be
version of shale test lib screwed
-
Key: TOMAHAWK-622
URL: http://issues.apache.org/jira/browse/TOMAHAWK-622
Project: MyFaces Tomahawk
Issue Type: Improvement
Reporter: Matthias Weßendorf
Ah, I see what you're talking about now.
Good catch. The outputting of the id is a nice improvement as well.
On 8/24/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: lfrohman
Date: Thu Aug 24 15:18:39 2006
New Revision: 434544
URL: http://svn.apache.org/viewvc?rev=434544&view=rev
Log
Also, and I know this isn't always possible, could you commit your
code cleanup separately from your code changes? It makes it really
hard to see what you've actually done if every line changes due to
formatting reasons :-)
On 8/24/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: tomsp
Problem #2 should not be happening if the MyFaces state management code is properly factored; the FormRenderer - anyone's form renderer - should be calling the ResponseStateManager, which should be rendering the sequence. Last time I looked, the MyFaces FormRenderer was directly encoding the s
I started to work on Trinidad and tomahawk incompatibilities.
Problem #1 (fixed partly)
When using the ADF form, tomahawk links won't work. The reason for
this: Tomahawk links are bound to the MyFaces form component.
This problem I could partly solve. I started off using an environment,
which is
It's good that everybody learns each day :)
after following this thread everybody knows (or should)
-iCLA is important
-going through the community is important
and Ernst did a nice job.
amen :)
On 8/24/06, Werner Punz <[EMAIL PROTECTED]> wrote:
Actually I have to take some blame on me as wel
Tomahawk DayRenderer move inner classes out make more methods protected vs
private
--
Key: TOMAHAWK-621
URL: http://issues.apache.org/jira/browse/TOMAHAWK-621
Project: My
On 8/24/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> I suspect what Adam is asking about is Shale getting in the business of
> creating visual components like buttons in order to implement the
> Next/Previous type of thing. That's an area I have wanted to shy away from,
> and this kind of thi
Actually I have to take some blame on me as well,
when Ernst asked me on how to get the code in
I told him to ask Catalin to do it, because
they currently share the same location in Frankfurt.
To my blame I was not aware of the entire ICLA issue.
Anway, please lets stop this discussion for now.
I
If I take on some SoC students next year, I'll make sure this happens
early on (with slightly more pressure than this year, cause I did ask
for filling out the ICLA in the beginning already this year, but not
everyone sent something in).
regards,
Martin
On 8/24/06, Craig McClanahan <[EMAIL
[ http://issues.apache.org/jira/browse/TOMAHAWK-618?page=all ]
Catalin Kormos updated TOMAHAWK-618:
Status: Patch Available (was: Open)
> Partial Page Rendering for tomahawk
> ---
>
> Key: TOMAHAWK-618
[
http://issues.apache.org/jira/browse/TOMAHAWK-579?page=comments#action_12430228
]
Wolf Benz commented on TOMAHAWK-579:
I'm using the tomahawk 1.1.5 version and having the same error...
Very annoying, the functionality to display an customi
This is especially important as coping with all different button, link
and form components is a nightmare already. Adding additional
components can only be adding to the problem here.
The combination of ADF-Faces, Tomahawk and the RI is (as of today)
impossible, e.g, if we don't cope for the spec
Due a bug in Weblogic 8.1 BodyTag classes must directly include the BodyTag
interface
-
Key: TOBAGO-117
URL: http://issues.apache.org/jira/browse/TOBAGO-117
Project:
Inline JavaScript does not get the same character encoding as the page
--
Key: TOMAHAWK-620
URL: http://issues.apache.org/jira/browse/TOMAHAWK-620
Project: MyFaces Tomahawk
This is not the first time that the use of JIRA for tracking changes
has come up.
http://www.mail-archive.com/dev@myfaces.apache.org/msg13737.html
Every commit has the possibility of breaking the codebase or changing
expected behavior, and having JIRA issues helps to know why and how
these chang
[
http://issues.apache.org/jira/browse/TOBAGO-117?page=comments#action_12430309 ]
Bernd Bohmann commented on TOBAGO-117:
--
javax.faces.FacesException: javax.servlet.ServletException: Since tag
class org.apache.myfaces.tobago.taglib.component
Hey Lance,
It's best to talk about these things on the dev list so everyone can
participate.
There are times (like now) where I'm very busy and I don't have time
to read every message posted, much less respond to an action item that
doesn't directly affect me.
I'm not sure what you mean by vali
[
http://issues.apache.org/jira/browse/TOMAHAWK-579?page=comments#action_12430231
]
Wolf Benz commented on TOMAHAWK-579:
Some additional info on this topic:
I thried out a few other things:
- have a pure JSP page instead of a JSF page gets t
[ http://issues.apache.org/jira/browse/TOBAGO-117?page=all ]
Bernd Bohmann resolved TOBAGO-117.
--
Resolution: Fixed
> Due a bug in Weblogic 8.1 BodyTag classes must directly include the BodyTag
> interface
> -
Hello,
can somebody kill the processid 19259 and restart continuum? I think
continuum is not running and i can't really stop it.
Regards
Bernd
I suspect what Adam is asking about is Shale getting in the business of
creating visual components like buttons in order to implement the
Next/Previous type of thing. That's an area I have wanted to shy away from,
and this kind of thing is a case in point for why. No matter what we do,
our navig
On 8/24/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
No I'm not proposing we deal with generating HTML rendering businessas far as dialogs are concerned. [I'll post a more detailedexplanation on the shale dev list where that belongs.]@Adam: If you're not already subscribed to shale dev we'd love
On 8/24/06, Catalin Kormos <[EMAIL PROTECTED]> wrote:
Hi guys,Sorry for the late reaction. Just want to say that i'm sorry about thesituation, I should have been more carefull, and this sort of things won'thappen next time. All your reactions were quite usefull and made me learn a
lot about ASF.I d
No I'm not proposing we deal with generating HTML rendering business
as far as dialogs are concerned. [I'll post a more detailed
explanation on the shale dev list where that belongs.]
@Adam: If you're not already subscribed to shale dev we'd love to have
you over there. Specifically, we could b
>From: "Adam Winer" <[EMAIL PROTECTED]> >Wrong list, sure, but since you opened up the can of worms...>>Is Shale really planning on getting into the HTML-rendering>business?>
What do you mean by "HTML-rendering business"?
We have custom components that do rendering. Clay has been around bette
Wrong list, sure, but since you opened up the can of worms...Is Shale really planning on getting into the HTML-renderingbusiness?-- AdamOn 8/24/06,
Sean Schofield <[EMAIL PROTECTED]> wrote:
Doh. Wrong list again.On 8/24/06, Sean Schofield <[EMAIL PROTECTED]> wrote:> I think it would be highly des
Well, that's for sure - in the beginning it should be in the sandbox,
and later on we decide!
regards,
Martin
On 8/24/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Hi!
> Yeah, right. I wouldn't mind a separate module either - it's not too
> big an overhead.
Not a big overhead?
Yet another d
Doh. Wrong list again.
On 8/24/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
I think it would be highly desirable to provide some sort of basic
button functionality ("previous, next, ok and cancel"). I'm not
saying we render buttons on the dialog for the user, but I am saying
that most dialogs
I think it would be highly desirable to provide some sort of basic
button functionality ("previous, next, ok and cancel"). I'm not
saying we render buttons on the dialog for the user, but I am saying
that most dialogs have certain things in common that we should just
incorporate into the basic fu
Hi.
I am not sure of the best implementation for this feature, but I want to note
that I think the feature itself would be valuable. My organization had to write
a custom export servlet to do just this for some of our data tables, so
providing this functionality within MyFaces may have been a nic
Hi!
> Yeah, right. I wouldn't mind a separate module either - it's not too
> big an overhead.
Not a big overhead?
Yet another directory in our "current" thingy, yet another entry in our
pom.xml and maybe another couple of poms for the module itself. Not to
speak about the release process and testi
I'm a bit confused here,
So the idea is to create a new tomahawk submodule like;
core
sandbox
examples
* goodies
* goodies with it's own jar, taglib?On 8/24/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
Yeah, right. I wouldn't mind a separate module either - it's not toobig an overhead.
regar
Yeah, right. I wouldn't mind a separate module either - it's not too
big an overhead.
regards,
Martin
On 8/24/06, Jesse Alexander (KSFD 121)
<[EMAIL PROTECTED]> wrote:
True ... BUT
imagine the doc you need to set up for the end-users:
dependencies for tomahawk: ---list of jar-files---
if you
True ... BUT
imagine the doc you need to set up for the end-users:
dependencies for tomahawk: ---list of jar-files---
if you want to use this component: add ---list of jar-files--- to the
above list
if you want ... and so on
It might be easier to separate them into a entity and then document th
Well, the dependency wouldn't be a run-time-dependency, much more a
compile-time-dependency.
regards,
Martin
On 8/24/06, Jesse Alexander (KSFD 121)
<[EMAIL PROTECTED]> wrote:
I think it would be a good idea to seperate such "heavy" components from
Tomahawk...
One reason I see is that maybe su
I think it would be a good idea to seperate such "heavy" components from
Tomahawk...
One reason I see is that maybe such libraries can be "banned" by
corporate-managers.
Users in such corporations could still use tomahawk... Others without
the restriction
just throw a few more jar-files into their
Hi guys,
Sorry for the late reaction. Just want to say that i'm sorry about the
situation, I should have been more carefull, and this sort of things won't
happen next time. All your reactions were quite usefull and made me learn a
lot about ASF.
Best regards,
Catalin
Matthias Wessendorf-4 wrot
Yes I agree with you Jurgen.
But It seems we don't know how far this exporting business will go. My
plan is to work at sandbox for now, when the time comes to do the
promotion, I guess we'll have a better understanding of the situation.
CagatayOn 8/24/06, Jurgen Lust <[EMAIL PROTECTED]> wrote:
>
> I think this situation is similar to the commons-fileupload dependency
> of the file upload component. I dont quite get the subproject idea
> Jurgen, can you explain it more? How is it gonna be distributed?
Well, there have been questions on the iText mailing list about
rendering PDF from JSF co
I don't know - how large is POI? Generally speaking, many users do
work with POI, so it might not be as large a problem, especially with
Maven.
(it wouldn't be the implementation which would come along with it,
only tomahawk)
regards,
Martin
On 8/24/06, Cagatay Civici <[EMAIL PROTECTED]> wrote
What library will you use to generate the Excel output? POI?
Yes POI.
Should we really make this a dependency for Tomahawk? I think it would
be better to put it in a different subproject. Some kind of
ExportRenderKit, which could also contain PDF renderers using iText, for
example.
I think this
What library will you use to generate the Excel output? POI?
Should we really make this a dependency for Tomahawk? I think it would
be better to put it in a different subproject. Some kind of
ExportRenderKit, which could also contain PDF renderers using iText, for
example.
Jurgen
Op wo, 23-08-200
46 matches
Mail list logo
