Re: [tomahawk] why bother with 1.2?
Hi! This code generation stuff does make code more *consistent* between the various bits (taglib, faces-config, java) but definitely does not make it simpler to work with. IMO, it introduces a whole new set of concepts that will make it harder for new developers to get into this code. I too thought that the generating stuff is just about creating the tag handler for JSP/Facelets and the config files, but leave the component/renderer stuff itself untouched in the responsibility of the developer. For what I have seen till now, when I had to fix a problem in the templates I, I just can second that development is again getting more painful. I don't want to sound too negative, but first shared and now this :-( Ciao, Mario
Re: myfaces-faces-plugin - architecture
Hi Matthias, yep. -xml configuration == mini faces-config files -templates == in order to override some *defaults* (like when you want to do something special inside the validate() for InputFile, provide a template, which is a real Java class) -it generates the real UIComponent java file as well -generates facelets XML taglib file Is it possible to use the plugin in a way where the component/renderer gets not generated, only the tagblib and config stuff? I think this is the way to go for now. I know, then the developer has to ensure that the types of the setter on the UIComponent do not differ to the property. Another short term solution could be to just create an abstract basis class with the setter/getter stuff but leave the real logic of the component out of it. The developer then has to inherit from this class the real component. Ciao, Mario
Re: myfaces-faces-plugin - architecture
Hi Simon!
First, my intention was/is to find a solution. I don't think that we
manage to create an all new generator stuff. We had plenty of time in
the past to make this thing fly, but failed.
So, while I'd really support your idea about a annotation driven
generator, I don't think that we will see it even in the mid future. We
all have too much work to do - and unhappily no time.
can you investigate into the suggestion by Mario - I think this will
be even better (and easier to achieve) then generating the components
into the source-tree, as the old MyFaces component generator did.
IMO, the best solution is where the code checked in to svn *compiles*. IDE
auto-completion, refactoring, all the other tools that work only with *real*
code will then be usable again.
For sure, I thought we can generate the stuff and then commit the
generated files, so no need to regenerate for each build, just when
something in the component config changed.
@why Trinidad doesn't work with annotations: how would you then
generate restoreState and saveState? And the getters? You don't want
to write all the getters by hand, do you?
I'd be happy to see normal getter/setter methods in
component/validator/converter classes. Yes, it is a little more code but it
is *normal* code, that every java programmer can understand at a glance.
I am not 100% sure if the typical (if member is not null/else get
ValueExpression) is still required, but if it is it is worth generating
it, no?
On the other hand, with generics and the ValueExpression it should be
possible to encapsulate this in a simple utility method.
Said that, I have absolutely no problems in writing them by hand ... or
... to say the truth, let the IDE generate them.
The save and restore state stuff is a bit trickier. Yes, it would be nice to
avoid writing that by hand as it is error-prone. Personally I would be
*satisfied* (although not happy) to see the system just *verify* hand-written
code, if that meant that the stuff checked in to svn is real normal
compilable code. However I think that some better solution can be made, eg by
writing
protected Object[] saveState() {
return StateHelper.saveState(this.getClass());
}
I think it should be
StateHelper.saveState(this);
as you need access to the state of the current object ;-)
Anyway, this requires you to break into the class as you have to call
setAccessible on the private member fields of the component. I see some
problems with various installed Security-Managers, at least, I'd not assume to
being able to make them accessible.
Hmm
Ciao,
Mario
Re: myfaces-faces-plugin - architecture
Leonardo Uribe schrieb: For sure, I thought we can generate the stuff and then commit the generated files, so no need to regenerate for each build, just when something in the component config changed. Yep, this just works nicely if we go the abstract component route, no? else you'll lose all changes you applied on the generated code. Ciao, Mario
Re: myfaces-faces-plugin - architecture
Hi! 1) we do an abstract component base class, very clean, however, it will not work for MyFaces-AP I personally think we can go with option 1 only - there are not so many API classes, and changes in the API are not ocurring too often. +1 I have no problems if this does not work with the API stuff, even if another solution would be great, this is the best we can get given our all time constraints. As you said, anything else will allow us to work in a normal way with our IDEs. If it fits your needs, I also do not care if we checkin the generated files. But then, it is required that mvn eclipse:eclipse and mvn idea:idea correctly generate the files first and then adds them as additional source to the project. Probably this is possible. Said that, the question is what we would like to see in SVN. Some xml file changes where we do not know how they get woven into the generated files, or a well known svn history. So, from my current point of view I'd vote to checkin the generated files too. Ciao, Mario
Re: myfaces-faces-plugin - architecture
Hi! ok - then please suggest one. This is all about finding a clean way, and we are at this point as we haven't found another clean way to do it so far. I had a quick chat about this topic with Matthias and I think now I understood a little bit better what the thought how to work with the generator stuff. The idea is (as everyone migh know) to generate the config files/taglibs and (the discussed) component. Matthias said, that one normally does NOT have to change this class as the real work has to be done in the renderer. I am not fully convinced about that, but have to admit that I am not a full-blown-component developer - just some small pieces now and then. I told him that I think the component logic should live within the component - where he didnt disagree, but also pointed me to the fact that one can always have a abstract base renderer where the common code might live. I think that this not fully in sync with the component idea, but might work. In the end, it seems as if you could create 95% of all components without having to touch the generated class - as long as you just work with the renderer classes. Which means, no need for generating an abstract basis class. I am not sure if I like this standard, but wanted to write this as I think it helps to understand what the idea was/is behind all this. Sorry Matthias if I made some mistake in the summarize and probably misinterpreted one detail or another. But I think overall it is correct. Ciao, Mario
Re: myfaces-faces-plugin - architecture
Leonardo Uribe schrieb: Not have code completion and other features on the IDE is a low price for we have with templates. Not that I would like to veto at this point (which I am not able to do, for sure), but: We already gave up some comfort with having the shared stuff. You know, you can not easily set breakpoints, edit files, compile and retest. You know, you always have to know in which generated share to set the breakpoint and then change the core, regenerate etc etc. Afterwards, the same counts for the components too. Which means, lets say, 70% of the code can't be easily debugged, changed, hot-swapped etc. Given that it is hard already to find open-source developers I am not sure if all this is engouraging. But yes, I do not have any better idea yet. Ciao, Mario
Re: performance comparison between 1.1.5 and 1.2.2?
Hi!
Is it better to use plain html tags (if possible) instead of jsf-tags
e.g. for images, divs etc when no EL expressions are used ?
Yes, definitely. This is just a block of verbatim text, which is written
out very efficiently. Using a component to write the same text is much slower
and gains nothing.
And it looks nicer too..
I would not have answered if you would not have used the word
definitely ;-)
I'd prefer to use components only. With one exception, static texts -
but how many static texts do you have in an i18n enabled application :-)
Using components is just the base idea of JSF and in the long run I
think you are on the safe side using them.
For example, would you really write img
src=#{context.contextPath}/to/my/image.png / ?
Looks really like in g'ol days with JSP, no?
Having h:graphicImage src=/to/my/image.png / is not that much
longer, and saves you from the internals of the used servlet environment.
In the end it is all about personal preferences :-)
Ciao,
Mario
Re: [orchestra] rename scope flash to access
Hi Simon! Are there any objections? Sounds good! Ciao, Mario
Re: [orchestra] rename scope flash to access
Hi! Hmmm... I agree that flash can be misleading, but access doesn't seem very descriptive to me. I think page or view might be more appropriate. As it is currently in Orchestra, the fomer flash-scope is exactly an access-scope. As long as the bean is accessed it stay alive, regardles of the page it is used on. page or view are different scopes where one assumes that the bean vanishes as soon as another page is navigated to even if a conversation with the same name will be used here. We can discuss if such a scope makes sense for Orchestra I guess not. Ciao, Mario
Re: [vfs] Inconsistent Behavior...
Hi! I think your only chance is to use tcpdump and/or wireshark to debug the network flow to see the real answers of the ftp server. Or debug into the VFS code ... somewhere in doAttach in FtpFileObject and see whats going wrong in there. Sorry! Ciao, Mario Well, I ran it once and it said The file type is file and it succeeded, but then I ran it again and it says The file type is imaginary and it failed. Here's the code: final FileSystemManager fsm = VFS.getManager(); final FileObject remoteFile = fsm.resolveFile(ftp://ftp.ncbi.nih.gov/pub/HomoloGene/current/homologene.data;); System.out.println(The file type is + remoteFile.getType().getName() + .); final File tmp = File.createTempFile(download, .txt); tmp.deleteOnExit(); final FileObject tempFile = fsm.toFileObject(tmp); FileUtil.copyContent(remoteFile, tempFile); Here's the complete output: [EMAIL PROTECTED]:18:11 INFO (DefaultFileReplicator) - Using C:\Users\jcarman\AppData\Local\Temp\vfs_cache as temporary files store. [EMAIL PROTECTED]:18:12 DEBUG (StandardFileSystemManager) - Skipping provider org.apache.commons.vfs.provider.sftp.SftpFileProvider because required class com.jcraft.jsch.JSch is not available. [EMAIL PROTECTED]:18:12 DEBUG (StandardFileSystemManager) - Skipping provider org.apache.commons.vfs.provider.smb.SmbFileProvider because required class jcifs.smb.SmbFile is not available. [EMAIL PROTECTED]:18:12 DEBUG (SoftRefFilesCache) - putFile: ftp://ftp.ncbi.nih.gov/pub/HomoloGene/current/homologene.data [EMAIL PROTECTED]:18:12 DEBUG (SoftRefFilesCache) - putFile: ftp://ftp.ncbi.nih.gov/ [EMAIL PROTECTED]:18:12 DEBUG (SoftRefFilesCache) - putFile: ftp://ftp.ncbi.nih.gov/pub/HomoloGene/current [EMAIL PROTECTED]:18:12 DEBUG (SoftRefFilesCache) - putFile: ftp://ftp.ncbi.nih.gov/pub/HomoloGene [EMAIL PROTECTED]:18:12 DEBUG (SoftRefFilesCache) - putFile: ftp://ftp.ncbi.nih.gov/pub The file type is imaginary. [EMAIL PROTECTED]:18:13 DEBUG (SoftRefFilesCache) - putFile: file:///C:/Users/jcarman/AppData/Local/Temp/download14482.txt Exception in thread main org.apache.commons.vfs.FileSystemException: Could not read from ftp://ftp.ncbi.nih.gov/pub/HomoloGene/current/homologene.data; because it is a not a file. at org.apache.commons.vfs.provider.AbstractFileObject.getInputStream(AbstractFileObject.java:1149) at org.apache.commons.vfs.provider.DefaultFileContent.getInputStream(DefaultFileContent.java:360) at org.apache.commons.vfs.FileUtil.writeContent(FileUtil.java:71) at org.apache.commons.vfs.FileUtil.copyContent(FileUtil.java:103) I left out the project-specific parts of the stack trace because it's not relevant, but there were no nested exceptions. On 1/29/08, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! Did you get my second email? That's the entire output I got when I ran it. Uh, oh, ok! So then, it seems that VFS thinks the file is either a directory or non existent. Could you please: *) check the filetype of the FileObject see if its virtual or whatever *) try to connect to the ftp server using a commandline tool to see if the ftp output is in a style which makes it impossible for commons-net to parse the output, e.g. due to localized date format. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] Inconsistent Behavior...
Hi! Did you get my second email? That's the entire output I got when I ran it. Uh, oh, ok! So then, it seems that VFS thinks the file is either a directory or non existent. Could you please: *) check the filetype of the FileObject see if its virtual or whatever *) try to connect to the ftp server using a commandline tool to see if the ftp output is in a style which makes it impossible for commons-net to parse the output, e.g. due to localized date format. Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vfs] Inconsistent Behavior...
Hi! Could not read from ftp://ftp.ncbi.nih.gov/pub/HomoloGene/current/homologene.data; because it is a not a file. at org.apache.commons.vfs.provider.AbstractFileObject.getInputStream(AbstractFileObject.java:1149) at org.apache.commons.vfs.provider.DefaultFileContent.getInputStream(DefaultFileContent.java:360) at org.apache.commons.vfs.FileUtil.writeContent(FileUtil.java:71) at org.apache.commons.vfs.FileUtil.copyContent(FileUtil.java:103) at com.myco.MyLoader.main(MyLoader.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) Could you please post the whole stacktrace ... also the causes. Thanks! Ciao, Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VFS-195) Unable to get Zip file URL working on Windows machine
[ https://issues.apache.org/jira/browse/VFS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563142#action_12563142 ] Mario Ivankovits commented on VFS-195: -- Hmmm I think the examples on our web-page [1] are rather self-explaining, aren't they? I had no chance to test this on a windows machine yet, but my try on linux with the latest VFS snapshot the following worked: FileObject fo = VFS.getManager().resolveFile(zip:file:///home/im/Downloads/commons-compress-draft.zip); or FileObject fo = VFS.getManager().resolveFile(zip:file:///home/im/Downloads/commons-compress-draft.zip!/); If you do not use VFS.getManager() you have to ensure you setup VFS correctly e.g. by adding all wanted providers. As always, please try the latest nightly build too. BTW: Please do not use JIRA as disuccsion platform. I am going to close this bug again and looking forward that we help you on the user list until we all conclude that this is a bug. Ciao, Mario [1] http://commons.apache.org/vfs/filesystems.html#Zip__Jar_and_Tar Unable to get Zip file URL working on Windows machine - Key: VFS-195 URL: https://issues.apache.org/jira/browse/VFS-195 Project: Commons VFS Issue Type: Bug Affects Versions: 1.0 Reporter: Rajiv Kumar Could not get the Zip file URL working on Windows machine? Tried following formats. zip:file:/C:/Temp/source/test.zip --- Invalid Absolute URI zip:file:/C:/Temp/source/test.zip! --- Invalid Absolute URI zip:file://C:/Temp/source/test.zip --- Invalid Absolute URI zip:file:/C:/Temp/source/test.zip! -- Invalid Absolute URI zip://file:/C:/Temp/source/test.zip -- org.apache.commons.vfs.FileSystemException: Could not copy because it does not exist. zip:///C:/Temp/source/test.zip! - Could not copy because it does not exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Tomahawk Sandbox promotion schedule?
Hi! I'd also like to see submitOnEvent promoted. I've gotten a lot of use out of it, although I don't know how may others are using it. +1 to submitOnEvent I use it constantly too. Ciao, Mario
Re: embedded table
Hi Martin, I think I understood it now - you have a header per row for the details in this row, and also allow each main-row to have a header now? I am not sure if this describes it exactly - it is not about having headers. Or lets say, one header for three nested tables. Have a look at [1]. This demonstrates the table I have in mind. I've enabled the border for a better visual representation of what I mean. First of all, the whole table has a header (the first row) - This is also the first table. This first table points to a list with two entries (the two red rows). Each entry of this list also points to another list (the three yellow rows). Each entry of the yellow list also points to another list (the details) So we have three tables, the inner two with embedded=true to have the columns nicely aligned. Ciao, Mario [1] http://www2.ops.co.at/~im/table.html
Re: embedded table
Martin Marinschek schrieb: I don't get through to this server, sorry :( Sorry, try this one: http://www.ops.co.at/~opsj/table.html Ciao, Mario
Re: embedded table
Hi! Shouldn't this work somewhat similar to how the detailStamp in t:dataTable works now? Yep, why not, should work that way too. The real magic will be the embedded=true attribute to the datatable, and a different way how to define the column header for the master table. Ciao, Mario
[jira] Created: (TOMAHAWK-1181) allow to embed a datatable within the parent
allow to embed a datatable within the parent Key: TOMAHAWK-1181 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1181 Project: MyFaces Tomahawk Issue Type: New Feature Components: Extended Datatable Reporter: Mario Ivankovits As discussed in this thread http://marc.info/?l=myfaces-devm=120118289000330w=2 add a new attribute to the datatable which allows to reuse the layout of the parent table. The attribute name so far is embed=true|false where false is the default. When embed=true: * avoid rendering the table start/end tag * do not add the thead/tfoot tags around the header or footer - instead simply render them at the start/end of the embedded table * do not render the header cells using the th tag Probably we have to think about another way how to define the header on the parent datatable. Not sure about that yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [orchestra] nullpointer in AbstractViewControllerManager.getViewController - probably bad configuration?
Hi! I probably have changed something, which I am unable to find again, and I keep having this exception now: 2008-01-23 17:31:56,789 [btpool0-1] ERROR (PhaseListenerManager,77) - Exception in PhaseListener RENDER_RESPONSE(6) beforePhase. java.lang.NullPointerException at org.apache.myfaces.orchestra.viewController.AbstractViewControllerManager.getViewController(AbstractViewControllerManager.java:60) at From the stacktrace it looks like you issue a forward() in which case the OrchestraServletFilter might not kick in if you do not add the dispatcher configuration to the filter mapping. Something like this: filter-mapping filter-nameorchestraFilter/filter-name url-pattern*.faces/url-pattern dispatcherFORWARD/dispatcher dispatcherREQUEST/dispatcher /filter-mapping Hope this helps! Ciao, Mario
embedded table
Hi!
One thing in JSF which constantly worries me is, that it is not easily
possible to create a more complicated table layout with
group/group/detail style.
What I mean is somthing like this:
Name Column1 Column2
Data1HeaderInformation1
Sub1HeaderInformation1
Name1 10 20
Sub1HeaderInformation2
Name2 20 30
Data2HeaderInformation1
Sub2HeaderInformation1
Name3 40 50
Name5 60 70
This reflects a list in a list in a list.
Currently, with JSF there is no chance to nest tables in such a way
without rendering completely unrelated tables. The problem is, that the
sub tables then have their own column width and it is hard to make them
look as just one table.
I thought about a new attribute on the dataTable (embedded=true) which
avoids rendering the table/table attributes so that the rendered
table nicely nest into the parent table.
For sure, the user has to take care that the numer of columns are the
same among all tables, probably by using stuff like t:column colspan=.
Secondly, to make this fully usable, we need another way to define the
header of a table as the master table has to render a very special
header where one would like to mix in the header of the detail row.
For this, I thought we could use a facet directly on the datatable. In
the end, it might look like the following:
t:datable var=group1 value=#{bean.data}
f:facet name=columnHeader1
t:column colspan=2
t:outputText value=header /
/t:column
/f:facet
f:facet name=columnHeader2
t:column
t:outputText value=detailA /
/t:column
/f:facet
f:facet name=columnHeader3
t:column
t:outputText value=detailB /
/t:column
/f:facet
...
t:column colspan=10
t:outputText value=#{group1.headerValue} /
/t:column
/t:datable var=group2 value=#{group1.groupData} embedded=true
t:column colspan=2
t:outputText value=#{group2.headerValue2} /
/t:column
t:column colspan=8
t:outputText value=#{group2.headerValue2} /
/t:column
/t:datable var=detail value=#{group2.detailData}
embedded=true
t:column
t:outputText value=#{detail.value1} /
/t:column
t:column
t:outputText value=#{detail.value10} /
/t:column
/t:datable
/t:datable
/t:datable
I know, with facelets I can achive the same using plain html tags and
dataLists, but I STRONGLY prefer NOT to use such an approach, I'd like
to use ONLY components.
What do you think?
Ciao,
Mario
[jira] Updated: (MYFACES-1804) Pressing a download button corrupts other button actions in Internet Explorer
[
https://issues.apache.org/jira/browse/MYFACES-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivankovits updated MYFACES-1804:
--
Resolution: Duplicate
Status: Resolved (was: Patch Available)
It is so strange.
Two bugs uncovered by different people and filed in sequence. I can't belive it
:-) Way too cool.
MYFACES-1805 fixed it.
Pressing a download button corrupts other button actions in Internet Explorer
-
Key: MYFACES-1804
URL: https://issues.apache.org/jira/browse/MYFACES-1804
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.2.0
Environment: Microsoft internet Explorer 6.0 (not tested for other
versions)
Reporter: Thomas Fischer
Attachments: myfaces-1804.patch, testHiddenInputJavascript.html,
testie.jsp, TestieController.java
Situation: The user accesses a jsf page where a commandlink or commandButton
starts a download, and other commandLinks or CommandButtons are present in
the same form, using the internet explorer as a browser. The user e clicks on
the download Button. Afterwards, the user clicks on any other button in the
same form.
Observed behaviour: The previous download is started again, regardless of the
action associated with the button
Expected behaviour: The action associated with the button should be executed
Analysis: The error originates in the generated javascript function
oamSetHiddenInput(formname, name, value). In this function, it is checked
whether the hidden input already exists, using the javascript code
if(typeof form.elements[name]=='undefined')
This works fine in the Internet explorer as long as the hidden input was
created in html. If the hidden input was created using javascript, e.g. by
the code in the same function, the above condition returns true although the
hidden input already exists. This results in creating a second hidden input
field instead of replacing the value in the existing one. If the server only
uses the value of the first(i.e. already existing) hidden input field, it
gets the old value instead of the new one. In the end, myfaces reads the old
value of the html parameter ${formName}:_idcl, and so the old action is
executed instead of the new one.
Resolution: Accessing the hidden input via indices (form.elements[0],
form.elements[1] ...) also works if the hidden input is created dynamically.
Note that the error does only occur if the page is not reloaded when the
first button is pressed, so a special action as e.g. a download is needed to
trigger the behaviour.
I'd consider this to be a bug in IE, but as we cannot persuade all users to
use a browser which is less buggy, a workaround should be implemented in
myfaces. The error does not occur in Firefox.
As the implementation is in the myfaces_shared project, this affects both
core and tomahawk.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-194) Redirect of HTTP url using the header location
[
https://issues.apache.org/jira/browse/VFS-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561011#action_12561011
]
Mario Ivankovits commented on VFS-194:
--
could you attach a svn diff with the whole patch please.
Thanks!
Mario
Redirect of HTTP url using the header location
--
Key: VFS-194
URL: https://issues.apache.org/jira/browse/VFS-194
Project: Commons VFS
Issue Type: Wish
Environment: Windows XP/Linux/FreeBSD
Reporter: Yves Zoundi
The http provider classes don't test the header location before resolving a
file. If the redirection is reported as invalid by commons-httpclient, then
the HttpFileObject is not resolved. Here is how to fix it in all the http
provider implementation classes.
int status = 0;//client.executeMethod(method);
try{
status = client.executeMethod(method);
System.out.println(method executed);
}
catch(Exception e){
System.out.println(Exception co);
try{
HostConfiguration config =
client.getHostConfiguration();
Header header =
method.getResponseHeader(Location);
System.out.println(Checking header);
if (header != null) {
String redirectUrl = header.getValue();
config.setHost(new
java.net.URL(redirectUrl).getHost(), config.getPort(), config.getProtocol());
client.setHostConfiguration(config);
status = client.executeMethod(method);
}
}
catch(Exception err){
throw new Exception(err);
}
}
if ((status = 300) (status 400)) {
try{
HostConfiguration config =
client.getHostConfiguration();
Header header =
method.getResponseHeader(Location);
if (header != null) {
String redirectUrl = header.getValue();
method = new HeadMethod();
setupMethod(method);
config.setHost(new
java.net.URL(redirectUrl).getHost(), config.getPort(), config.getProtocol());
client.setHostConfiguration(config);
status = client.executeMethod(method);
}
}
catch(Exception err){
throw new Exception(err);
}
}
method.releaseConnection();
if (status == HttpURLConnection.HTTP_OK)
{
return FileType.FILE;
}
else if (status == HttpURLConnection.HTTP_NOT_FOUND
|| status == HttpURLConnection.HTTP_GONE)
{
return FileType.IMAGINARY;
}
else
{
throw new FileSystemException(vfs.provider.http/head.error,
getName());
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1805) form stopped working after ajax request
form stopped working after ajax request --- Key: MYFACES-1805 URL: https://issues.apache.org/jira/browse/MYFACES-1805 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0, 1.1.5 Reporter: Mario Ivankovits In a little bit complicated form using multiple PPR areas the datascroller attached to a datatable stopped working with InternetExplorer after the first ajax request. MyFaces always sent the current page again. It turned out that the code in oamSetHiddenInput is not fully compatible with InternetExplorer. The problem is that even after adding the element to the form using javascript the check for it (typeof form.elements[name]=='undefined') still returns undefined. After setting the id of the created element (beside of it's name) fixed this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1805) form stopped working after ajax request
[ https://issues.apache.org/jira/browse/MYFACES-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved MYFACES-1805. --- Resolution: Fixed Fix Version/s: 1.2.2-SNAPSHOT 1.1.6-SNAPSHOT committed to both myfaces version (1.1, 1.2) form stopped working after ajax request --- Key: MYFACES-1805 URL: https://issues.apache.org/jira/browse/MYFACES-1805 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.5, 1.2.0 Reporter: Mario Ivankovits Fix For: 1.1.6-SNAPSHOT, 1.2.2-SNAPSHOT In a little bit complicated form using multiple PPR areas the datascroller attached to a datatable stopped working with InternetExplorer after the first ajax request. MyFaces always sent the current page again. It turned out that the code in oamSetHiddenInput is not fully compatible with InternetExplorer. The problem is that even after adding the element to the form using javascript the check for it (typeof form.elements[name]=='undefined') still returns undefined. After setting the id of the created element (beside of it's name) fixed this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Is their a road map for Shale? was(Re: Misc)
Hi! MyFaces is really pretty large already. I try to avoid to have the next Jakarta ;-) What was the problem with Jakarta? The only thing we should not being afraid of is to split the myfaces mailinglist once traffic for a module of myfaces is getting too heavy and there is a significant community base maintaining the code. I think this will avoid making myfaces look like gozilla. Ciao, Mario
[jira] Commented: (MYFACES-1802) FacesException and nested exceptions
[ https://issues.apache.org/jira/browse/MYFACES-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558369#action_12558369 ] Mario Ivankovits commented on MYFACES-1802: --- I'd check the existence of getCause() using reflection as then it will also work with pre Java 1.4 Exceptions implementing getCause() - for example those Exceptions prepared to be backward compatible. FacesException and nested exceptions Key: MYFACES-1802 URL: https://issues.apache.org/jira/browse/MYFACES-1802 Project: MyFaces Core Issue Type: Bug Components: JSR-127 Affects Versions: 1.1.5 Reporter: Bernhard Huemer Attachments: MyFaces-1802.patch The JSF 1.1 specification requires any implementation to support Java 1.3 and that's why the FacesException isn't allowed to utilize builtin exception chaining mechanisms (i.e. initCause(), etc..) as they have been introduced in Java 1.4. However, the FacesException retains it's cause by delegating to the parent's constructor (for example, super(cause); or super(message, cause);). Although this bug is rather easy to fix, I've assigned the priority level 'Major' as it breaks the specification. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r610323 - in /myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/renderkit/html/util: DefaultAddResource.java MyFacesResourceLoader.java ResourceLoader.java
Hi Simon! public void serveResource(ServletContext context, HttpServletRequest request, -HttpServletResponse response, String resourceUri) throws IOException; +HttpServletResponse response, String resourceUri) +throws IOException, ClosedSocketException; I am not sure if this is binary compatible. In any case, it would be safe to make CSE extend IOException (which in fact it is, no?) which will avoid the need to extend the interface. You still can catch that one, just ensure the ordering in the catch clause - but you know :-) Ciao, Mario
Re: How to use one subview more than once in one page
Hi!
% String beanName = request.getParameter(beanName); %
tc:panel
f:facet name=layout
tc:gridLayout rows=fixed columns=1*;1*;1*/
/f:facet
tc:out id=out value='%= #{ + beanName + .value} %'/
tc:in id=in value='%= #{ + beanName + .value2} %'/
Woho would never have thought about such a solution myself :-)
kudos to you.
If you already use tomahawk have a look at the aliasBean which allows
you to get rid of the JSP stuff.
t:aliasBeansScope
t:aliasBean alias=#{quickSwitchToolbarData}
value=#{toolbar.toolbarData}
jsp:include page=xyz.page /
/t:aliasBean
/t:aliasBeansScope
This allows you to use quickSwitchToolbarData from within your include.
Ciao,
Mario
Re: orchestra with plain hibernate
Hi! WOW that was quick. If you also have an exitsing ApplicationContext.xml file and an example DAO, that would help a lot. I specially dont know what object will be injected into the DAO instead of the EntityManager from the regular examples. Ok, I took the time to setup the long awaited orchestra goodies project [1]. There you'll find a myfaces-orchestra-hibernate which consists of two modules. * myfaces-orchestra-hibernate-core * myfaces-orchestra-hibernate-examples The core currently just holds the HibernatePersistencesContextFactory. The examples module holds a VERY simple (and probaby wrong - quick-and-dirty - from the top of my head hacked) test app. Just checkout the tree as described here [2] and do a mvn install, afterwards cd into the examples module and call mvn jetty:run. This will startup a local servlet container waiting on port 9090 for your browser to connect. The simple example shows that the entities are the same between the requests which indicates an ongoing conversation and allows you to easily change their data. The Button new Conversation invalidates the current conversation which will start a new one immediately - resulting in new instances of the entity objects. As you might see, the example use a simple DAO extending the HibernateDaoSupport. Wheter you use this or any other Spring way to deal with Hibernate is upt to you, also if you use the @Transactional annotation for transaction demarcation or not is up to you. Any standard Spring way should do the trick. Orchestra transparently sits in between and ensures to provide the same (Hibernate)Session for the ongoing conversation. I hope everything is setup correctly, else come up again. Ciao, Mario [1] http://code.google.com/p/myfaces-orchestra-goodies/ [2] http://code.google.com/p/myfaces-orchestra-goodies/source
[jira] Created: (MYFACES-1798) DefaultViewHandlerSupports fails detecting extension if there are dots in the path
DefaultViewHandlerSupports fails detecting extension if there are dots in the
path
--
Key: MYFACES-1798
URL: https://issues.apache.org/jira/browse/MYFACES-1798
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Mario Ivankovits
Assignee: Mario Ivankovits
For example: With /myStrange.path/view.jsp the extension .path/view.jsp
will be derived.
In DefaultViewHandlerSupport a wrong regular expression is used to extract the
extension.
I'll try to change this to a simple string.lastIndexOf('.') as this should do
exactly what we want.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-1790) HtmlColumnTag.getComponentType returns the wrong value
[ https://issues.apache.org/jira/browse/MYFACES-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1225#action_1225 ] imario edited comment on MYFACES-1790 at 1/3/08 2:19 AM: --- This fixed broke the HtmlColumn component as now is tag (HtmlColumnTag) creates a UIColumn component instead of a HtmlColumn. was (Author: imario): This fixed broke the HtmlColumn component as now it tag creates a UIColumn component instead of a HtmlColumn HtmlColumnTag.getComponentType returns the wrong value -- Key: MYFACES-1790 URL: https://issues.apache.org/jira/browse/MYFACES-1790 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0 Reporter: Cameron Bateman Assignee: Matthias Weßendorf Fix For: 1.2.1 According to the spec, the component type of the default h:column tag is supposed to be javax.faces.Column, however HtmlColumnTag returns javax.faces.HtmlColumn. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MYFACES-1790) HtmlColumnTag.getComponentType returns the wrong value
[ https://issues.apache.org/jira/browse/MYFACES-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits reopened MYFACES-1790: --- This fixed broke the HtmlColumn component as now it tag creates a UIColumn component instead of a HtmlColumn HtmlColumnTag.getComponentType returns the wrong value -- Key: MYFACES-1790 URL: https://issues.apache.org/jira/browse/MYFACES-1790 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0 Reporter: Cameron Bateman Assignee: Matthias Weßendorf Fix For: 1.2.1 According to the spec, the component type of the default h:column tag is supposed to be javax.faces.Column, however HtmlColumnTag returns javax.faces.HtmlColumn. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: HtmlColumn 1.2
Matthias Wessendorf schrieb: I think the TAG-Clazz should cast against UIColumn (instanceof) and not against HtmlColumn; Ok, I'll do that, still, I think there is something very wrong if we have to check for this special case in the generator all around. Ciao, Mario
Re: HtmlColumn 1.2
Hi! After checking against ri and spec; I think we do it in the right way. The component type in htmlcolumntag is javax.faces.column and the component-type in standard-config for htmlcolumn is javax.faces.HtmlColumn. I think the componentType in HtmlColumnTag should be javax.faces.HtmlColumn. This is what the standard-faces-config.xml reflects too. With javax.faces.HtmlColumn you get a javax.faces.component.html.HtmlColumn, and with javax.faces.Column you get a javax.faces.component.Column. If the spec thinks a component type of javax.faces.Column should create a HtmlColumn it is wrong, no? I need to have this fixed to being able to proceed with another myfaces-1.2 fix - and with my project ... Ciao, Mario
Re: HtmlColumn 1.2
Hi! AFAIK this tag-class is the only tag that the RI folks don't generate. I don't like to fuck the plugin as well; so we could have this tag as real code as well; regarding the std-faces-cfg I agree that HtmlColumn should reflect it's type. With wrong, you talk about the UIColumn (since 1.2) itself ? I think that mapping the javax.faces.Column to HtmlColumn in the HtmlColumnTag is wrong. If it is required by the spec, then the spec is wrong, no? Though, I don't know what's the idea behind all this I just don't think that any other component behaves that way. Ciao, Mario
[jira] Resolved: (MYFACES-1798) DefaultViewHandlerSupports fails detecting extension if there are dots in the path
[
https://issues.apache.org/jira/browse/MYFACES-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivankovits resolved MYFACES-1798.
---
Resolution: Fixed
Fix Version/s: 1.2.2-SNAPSHOT
DefaultViewHandlerSupports fails detecting extension if there are dots in the
path
--
Key: MYFACES-1798
URL: https://issues.apache.org/jira/browse/MYFACES-1798
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Mario Ivankovits
Assignee: Mario Ivankovits
Fix For: 1.2.2-SNAPSHOT
For example: With /myStrange.path/view.jsp the extension .path/view.jsp
will be derived.
In DefaultViewHandlerSupport a wrong regular expression is used to extract
the extension.
I'll try to change this to a simple string.lastIndexOf('.') as this should do
exactly what we want.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1798) DefaultViewHandlerSupports fails detecting extension if there are dots in the path
[
https://issues.apache.org/jira/browse/MYFACES-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1267#action_1267
]
Mario Ivankovits commented on MYFACES-1798:
---
I think I fixed the last-dot-after-last-slash issue by searching and comparing
both character positions requiring the last dot after the last slash.
Regarding the double-extension issue. I'll leave this as room for improvements
by the community once required.
DefaultViewHandlerSupports fails detecting extension if there are dots in the
path
--
Key: MYFACES-1798
URL: https://issues.apache.org/jira/browse/MYFACES-1798
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Mario Ivankovits
Assignee: Mario Ivankovits
Fix For: 1.2.2-SNAPSHOT
For example: With /myStrange.path/view.jsp the extension .path/view.jsp
will be derived.
In DefaultViewHandlerSupport a wrong regular expression is used to extract
the extension.
I'll try to change this to a simple string.lastIndexOf('.') as this should do
exactly what we want.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1789) UIData do not honor first and row value binding in decode
UIData do not honor first and row value binding in decode - Key: MYFACES-1789 URL: https://issues.apache.org/jira/browse/MYFACES-1789 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0 Reporter: Mario Ivankovits Assignee: Mario Ivankovits UIData do not honor first and row value binding in decode. If rows= and first= points to a valueBinding during decode these values will not correctly taken by evaluating the valuebinding but the local literal values will be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1789) UIData do not honor first and row value binding in decode
[ https://issues.apache.org/jira/browse/MYFACES-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved MYFACES-1789. --- Resolution: Fixed Don't know the current release status, so leaving Unknown as Fix Version for now. UIData do not honor first and row value binding in decode - Key: MYFACES-1789 URL: https://issues.apache.org/jira/browse/MYFACES-1789 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0 Reporter: Mario Ivankovits Assignee: Mario Ivankovits UIData do not honor first and row value binding in decode. If rows= and first= points to a valueBinding during decode these values will not correctly taken by evaluating the valuebinding but the local literal values will be used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [commons] What Logger ?
hi,
basically yes, thats what I thought.
Not sure if registering resource bundles is the way to go as this leads to
duplicate/overridden keys then. Think what happens if you have 80+ libraries
everyone registering a resource bundle.
Thats why I thought it should be the responsibility of the app.
Hmmm ... What about extendig the log api with something like
log.warn(textKeyMapper, string key, object ... args)
or even better
Log log = LogFactory.getLog(textKeyMapper, clazz)
the textKeyMapper (or whatever name) is a simple interface like
string getLanguageText(string key)
or renaming it to TextFormatter with
string formatText(string key, object ... args)
The app then could use whatever it would like to to translate the key.
Not everyone uses resourcebundles.
If registering such a thing globally means you also have to deal with a scope
(regexp against class-name ?) where the resource bundle should be applied. This
to avoid the thing said in the first paragraph in this mail.
Reg cl: now that most classloader issues have been fixed you'd render it end of
live?!? Open-Sourceish, I know ;-)
I still dont get it ... and do not reach a pc till afternoon. But all of the
above could make it into cl too. I wont reiterate what I've wrote already.
I'll abstain from a negative vote ... You probably know better and I am
flexible enough to setup our app as required. Hopefully our users will think
the same :-)
Mario
-Original Message-
From: simon [EMAIL PROTECTED]
Date: Sunday, Dez 16, 2007 9:17 am
Subject: Re: [commons] What Logger ?
To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces
Development dev@myfaces.apache.org
Hi Mario,
You mean a myfaces-commons-logging module, that the following depend on?
* myfaces-commons-*
* myfaces-core
* myfaces-trinidad
The problem again is that each of those has its own resource bundle for its
messages, and that there would need to be some mechanism for it to inform the
myfaces-commons-logging module about them.
It seems that it might be easier to provide patches to slf4j to register
resource bundles for specific category strings, eg
org.slf4j.LoggerFactory.registerResource(
String category,
String bundleName);
But then the question is how such a call would be triggered. Maybe a static
block on an important class in every library could be used to
trigger that..seems sane at first thought, although logging is so
surprisingly tricky I am hesitant to say that any new feature is
actually possible.
Not sure how the SLF4J project would see that kind of patch. I'll ask though..
The same kind of functionality could be added to commons-logging too I guess.
But I had hoped commons-logging was at the end of its development life..
Regards,
Simon
On Sat, 2007-12-15 at 20:07 +0100, Mario Ivankovits wrote:
this sounds like yet another complexity.
I18n can be solved by a custom app layer even easier, no?
So this would mean we should go your custom myfaces logger wrapper. I would
not complain if commons depend on it, I think.
Mario
-Original Message-
From: simon [EMAIL PROTECTED]
Date: Saturday, Dez 15, 2007 8:00 pm
Subject: Re: [commons] What Logger ?
To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces
Development dev@myfaces.apache.org
The issue is that Trinidad (ADF faces) has always emitted
internationalised log messages, by using its own logging implementation.
But commons-logging does not offer any help for that. If code wants to emit
a log message that can be internationalised, it looks like this:
if (log.isDebugEnabled()) {
String msg = TrinidadMsgFormatter.format(SomeMsgKey, arg1, arg2);
log.debug(msg);
}
This is certainly inconvenient.
The slf4j equivalent looks like this:
log.debug(SomeMsgKey, arg1, arg2);
which at initial glance seems nicer.
However there are a number of gotchas. The most important is how the
resources are found to map (key, args) to a sensible message.
If the underlying logging impl
Re: [site] preferred doc format for website
Sorry, resending to dev list. Hi! And why not helping fixing the tomahak component? Shouldn't we stop duplicating work and making the user worring about which comp-lib to choose? Mario -Original Message- From: Matthias Wessendorf [EMAIL PROTECTED] Date: Saturday, Dez 15, 2007 3:36 pm Subject: Re: [site] preferred doc format for website To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org -1 on APT +1 on XML On Dec 15, 2007 3:29 PM, Simon Kitching [EMAIL PROTECTED] wrote: Hi All, I'm experimenting with some changes to the myfaces site. I see that there are some files in maven APT format, and some in XDOC. Which is the preferred format for files? In particular, I'd like to split docs into versions that explicitly talk about either JSF11 or JSF12. Which format should I write the new files in? Personally, I'm currently neutral. XML can be a pain sometimes, and is less readable in raw form. However xdoc is a standard while APT is maven-specific. Opinions? Regards, Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Trinidad] Issue with Tomahawk integration - Schedule component
Heaven, must still be drunken .. Hi! And why not helping fixing the tomahak component? Shouldn't we stop duplicating work and making the user worring about which comp-lib to choose? Mario -Original Message- From: Matthias Wessendorf [EMAIL PROTECTED] Date: Saturday, Dez 15, 2007 3:15 pm Subject: Re: [Trinidad] Issue with Tomahawk integration - Schedule component To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org would be good, if the model would be similar -M On Dec 14, 2007 6:09 PM, Andrew Robinson [EMAIL PROTECTED] wrote: First use the users@ and not dev@ for all usage questions. Don't hold me to it, but I plan on creating a trinidad calendar component, as I want one myself. It will be a while before I start it though. -Andrew On Dec 13, 2007 4:52 AM, Mustafa DEMÝR [EMAIL PROTECTED] wrote: Hello, i am a new myfaces-trinidad developer. I am developing a course projet using myfaces tomahawk. Tomahawk schedule component is crucial for me. But when i am integrating trinidad ( after configuring web.xml and faces-config file according to here), my schedule component is not working properly (mouselistener, actionlistener etc).. When i clicked the schedule entry, my page only refreshes without calling my listener and action. Also there is no trinidad component in may page. What can be the problem? Thanks for your help. Regards. Mustafa Demir -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [site] preferred doc format for website
still drunken seems like. sorry for the noise. Mario -Original Message- From: Mario Ivankovits [EMAIL PROTECTED] Date: Saturday, Dez 15, 2007 3:58 pm Subject: Re: [site] preferred doc format for website To: Reply-MyFaces Development dev@myfaces.apache.orgReply-To: [EMAIL PROTECTED]: dev@myfaces.apache.org Sorry, resending to dev list. Hi! And why not helping fixing the tomahak component? Shouldn't we stop duplicating work and making the user worring about which comp-lib to choose? Mario -Original Message- From: Matthias Wessendorf [EMAIL PROTECTED] Date: Saturday, Dez 15, 2007 3:36 pm Subject: Re: [site] preferred doc format for website To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org -1 on APT +1 on XML On Dec 15, 2007 3:29 PM, Simon Kitching [EMAIL PROTECTED] wrote: Hi All, I'm experimenting with some changes to the myfaces site. I see that there are some files in maven APT format, and some in XDOC. Which is the preferred format for files? In particular, I'd like to split docs into versions that explicitly talk about either JSF11 or JSF12. Which format should I write the new files in? Personally, I'm currently neutral. XML can be a pain sometimes, and is less readable in raw form. However xdoc is a standard while APT is maven-specific. Opinions? Regards, Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [commons] What Logger ?
does this mean EVERY user has to drop in a slf4j jar then? Why not stick with cl and those willing to use sl4j drop in the adapter jar? Mario -Original Message- From: Matthias Wessendorf [EMAIL PROTECTED] Date: Saturday, Dez 15, 2007 5:53 pm Subject: [commons] What Logger ? To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org Hi, I think, I'll use http://slf4j.org/ for the logger in commons. What do you think about that ? -M -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [commons] What Logger ?
could you explain what we gain from that switch? I just see one additional jar as the user has to deal with cl anyway. It is the defacto standard. Did you consider the java std log facility. Might be as good as sl4j. A cl adapter might be doable there too. Mario -Original Message- From: Matthias Wessendorf [EMAIL PROTECTED] Date: Saturday, Dez 15, 2007 7:12 pm Subject: Re: [commons] What Logger ? To: MyFaces Development dev@myfaces.apache.org, [EMAIL PROTECTED] I think, that Manfredo will also put it into myfaces-core :-) Simon suggested to create a MyFaces Logger, but... commons should not depend on that. (a cool discussion on the hackaton) -M On 15 Dec 2007 19:01:00 +0100, Mario Ivankovits [EMAIL PROTECTED] wrote: does this mean EVERY user has to drop in a slf4j jar then? Why not stick with cl and those willing to use sl4j drop in the adapter jar? Mario -Original Message- From: Matthias Wessendorf [EMAIL PROTECTED] Date: Saturday, Dez 15, 2007 5:53 pm Subject: [commons] What Logger ? To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org Hi, I think, I'll use http://slf4j.org/ for the logger in commons. What do you think about that ? -M -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [commons] What Logger ?
this sounds like yet another complexity.
I18n can be solved by a custom app layer even easier, no?
So this would mean we should go your custom myfaces logger wrapper. I would not
complain if commons depend on it, I think.
Mario
-Original Message-
From: simon [EMAIL PROTECTED]
Date: Saturday, Dez 15, 2007 8:00 pm
Subject: Re: [commons] What Logger ?
To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces
Development dev@myfaces.apache.org
The issue is that Trinidad (ADF faces) has always emitted
internationalised log messages, by using its own logging implementation.
But commons-logging does not offer any help for that. If code wants to emit a
log message that can be internationalised, it looks like this:
if (log.isDebugEnabled()) {
String msg = TrinidadMsgFormatter.format(SomeMsgKey, arg1, arg2);
log.debug(msg);
}
This is certainly inconvenient.
The slf4j equivalent looks like this:
log.debug(SomeMsgKey, arg1, arg2);
which at initial glance seems nicer.
However there are a number of gotchas. The most important is how the resources
are found to map (key, args) to a sensible message.
If the underlying logging implementation is i18n-aware then SLF4j jus tpasses
the data on. But the underlying impl still needs to somehow know how to find
the Trinidad resource bundles in order to create sensible logging messages. I
don't have any experience with i18n-aware logging systems, so I'll leave that
to others to comment on how easy/difficult it is to arrange that.
But AFAIK if the underlying logging implementation is *not* i18n-aware, then
the message written to the log will simply be SomeMsgKey, with all info
about the actual params lost. This, for example, is the default SLF4J
behaviour when configured to forward messages to commons-logging or log4j.
Regards,
Simon
On Sat, 2007-12-15 at 18:32 +, Bruno Aranda wrote:
And sorry, I do not know sl4j, what do we gain with it? Thanks!
Bruno
On 15 Dec 2007 19:26:00 +0100, Mario Ivankovits [EMAIL PROTECTED] wrote:
could you explain what we gain from that switch?
I just see one additional jar as the user has to deal with cl anyway.
It is the defacto standard.
Did you consider the java std log facility. Might be as good as sl4j.
A cl adapter might be doable there too.
Mario
-Original Message-
From: Matthias Wessendorf [EMAIL PROTECTED]
Date: Saturday, Dez 15, 2007 7:12 pm
Subject: Re: [commons] What Logger ?
To: MyFaces Development dev@myfaces.apache.org, [EMAIL PROTECTED]
I think, that Manfredo will also put it into myfaces-core
:-)
Simon suggested to create a MyFaces Logger,
but... commons should not depend on that.
(a cool discussion on the hackaton)
-M
On 15 Dec 2007 19:01:00 +0100, Mario Ivankovit
Re: [Trinidad] Issue with Tomahawk integration - Schedule component
Hi! And why not helping fixing the tomahak component? Shouldn't we stop duplicating work and making the user worring about which comp-lib to choose? Mario -Original Message- From: Andrew Robinson [EMAIL PROTECTED] Date: Friday, Dez 14, 2007 6:09 pm Subject: Re: [Trinidad] Issue with Tomahawk integration - Schedule component To: Reply-MyFaces Discussion users@myfaces.apache.orgTo: MyFaces Development [EMAIL PROTECTED], MyFaces Discussion users@myfaces.apache.org First use the users@ and not dev@ for all usage questions. Don't hold me to it, but I plan on creating a trinidad calendar component, as I want one myself. It will be a while before I start it though. -Andrew On Dec 13, 2007 4:52 AM, Mustafa DEMÝR [EMAIL PROTECTED] wrote: Hello, i am a new myfaces-trinidad developer. I am developing a course projet using myfaces tomahawk. Tomahawk schedule component is crucial for me. But when i am integrating trinidad ( after configuring web.xml and faces-config file according to here), my schedule component is not working properly (mouselistener, actionlistener etc).. When i clicked the schedule entry, my page only refreshes without calling my listener and action. Also there is no trinidad component in may page. What can be the problem? Thanks for your help. Regards. Mustafa Demir
Re: svn commit: r602459 - /myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/AbstractSpringOrchestraScope.java
Sorry for the whitespace stuff, I thought I reverted them.
This one is the real patch:
Author: imario
Date: Sat Dec 8 05:05:14 2007
New Revision: 602459
URL: http://svn.apache.org/viewvc?rev=602459view=rev
Log:
fixed regression regarding viewController scope
Modified:
myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/AbstractSpringOrchestraScope.java
@@ -231,13 +231,11 @@
Object proxy =
beanDefinition.getAttribute(ScopedBeanTargetSource.class.getName());
if (proxy == null)
{
if (log.isDebugEnabled())
{
log.debug(getProxy: creating proxy for +
beanName);
}
- String conversationName = (String)
beanDefinition.getAttribute(BeanDefinitionConversationNameAttrDecorator.CONVERSATION_NAME_ATTRIBUTE);
- if (conversationName == null)
- conversationName = beanName;
+ String conversationName =
getConversationNameForBean(beanName);
BeanFactory beanFactory =
applicationContext.getBeanFactory();
proxy = _SpringUtils.newProxy(this, conversationName,
beanName, objectFactory, beanFactory);
beanDefinition.setAttribute(ScopedBeanTargetSource.class.getName(), proxy);
Ciao,
Mario
[jira] Commented: (ORCHESTRA-13) RequestParameterProviderManager fails when template URL includes EL expressions
[
https://issues.apache.org/jira/browse/ORCHESTRA-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548721
]
Mario Ivankovits commented on ORCHESTRA-13:
---
But the RequestParameterProvidedManager should not see any url with
el-expressions in it.
The UrlParameterNavigationHandler should have replaced them all.
If this didn't work I see two possible problems:
1) UrlParameterNavigationHandler is not configured correctly (needs to be done
manually, is not setup by orchestra)
2) The UrlParameterNavigationHandler is broken :-(
RequestParameterProviderManager fails when template URL includes EL
expressions
---
Key: ORCHESTRA-13
URL: https://issues.apache.org/jira/browse/ORCHESTRA-13
Project: MyFaces Orchestra
Issue Type: Bug
Components: RequestParameterProvider
Affects Versions: 1.0
Reporter: Simon Kitching
As reported by Jonas Esser on the mailing list, a url of form
http://foo.example?productId=#{var}
fails badly; the final url is:
http://foo.example?productId=contextId=1val
This occurs in the petstore orchestra example, when viewing a product's
details.
The problem is that RequestParameterProvidedManager thinks the # is a url
fragment marker. Query params go before fragment markers, eg
http://foo.example?productId=5#anchor
does correctly become
http://foo.example?productId=5contextId=1#anchor
But #{...} is NOT an anchor. In the petstore example, the url can be found in
faces-config.xml:
navigation-case
from-outcomeProductDetails/from-outcome
to-view-id/mops/ProductDetail.jsp?productId=#{param.productId}/to-view-id
redirect/
/navigation-case
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: MyFaces logo :)
Hi! 1. The Blue-Orange, two complementary colors, has a strong contrast, but in my opinion blue is a very common color in many logos now a days in special ICEfaces has a blueish logo. +1 Thats my favorite! This also allows us nicely to adjust the site colors. 2. The Apache red-Apache yellow, inspired from the apache Indians clothes and art objects. In my opinion this is an interesting color combination, a good candidate for the final color scheme +0 Wouldn't it be hard to create a web-page out of these color combination. If not, I can get used to it too. 3. The most appreciated color combination from the previous logo snapshot. It's actually my favorite combination, is a good balancing between two harmonious colors. Also green transmits the sensation of the environment friendly technology, a present and future trend in many organizations. -1 For me this color combination is too earthy - and resuts in an overall dark color scheme I think. Ciao, Mario
Re: Portlet Bridge logo
Hi! Here are the possible Logo's that Adonis forwarded me for the bridge project. Anyone have any preferences? I think I like the ones in logo_3 better but not sure which one. In logo_3 I like 3 and 7, where I'd opt for 7 as this is stylish enough to not be a bridge but still remembers one about it. Simple and mnemonic. Ciao, Mario
Re: [commons] structure proposal...
Hi! I am fine with that, just, I'd change the name commons for validators/converters/fileupload /commons/ -/myfaces-validators -... or what ? I thought more about /commons/ -/myfaces-commons-utils /newprojectname/ -/myfaces-newprojectname-validators -/myfaces-newprojectname-converters -/myfaces-newprojectname-ppr -/myfaces-newprojectname-grids -/myfaces-newprojectname-layouters We really should think about that as the long awaited fusion of the best possible techniques at myfaces - proven to work together nicely. Hrm.. not sure if a *common* PPR is really fine. Trinidad, for instance doesn't need anything from dojo, so we have our very simple and lightweight ajax-API. Thats the nice thing about modularizing tomahaw/trinidad. If one would like to use our ppr, adding our jar would be enough, and ... So, adding dojo, as a common mechanism to Trinidad, is not really something, I am thrilled about. ... it is not put in stone that the ppr project above is based on the tomahawk-sandbox-ppr. BTW: If a component itself is ajaxable without any additional ppr lib it should work too. but, we can bring this up in the future, current goal is, to just kickoff the base of commons. As the discussion has come so far - I think - the least common denominator is just the myfaces-commons-utils project and even there it seems we are not able to work out if we should split it into -api/-impl. Sorry to have to say that. Ciao, Mario
Re: [commons] structure proposal...
Hi! I thought more about /commons/ -/myfaces-commons-utils /newprojectname/ -/myfaces-newprojectname-validators -/myfaces-newprojectname-converters -/myfaces-newprojectname-ppr -/myfaces-newprojectname-grids -/myfaces-newprojectname-layouters no real need for a new project name, IMO Please notice that newprojectname ist not located under commons! The question is, what makes the result of the fission ;-) of tomahawk and trinidad more common than any other project. Why should it deserve the name commons? like /commons -/myfaces-validator -/api -/impl -/myfaces-converter -/api -/impl Isn't that a bit to much ? I think too. Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Hi! I don't think a separation between api and impl jars is useful. I second that. For the same reasons. It makes things unnecessary complicated To ensure api stability community review should be enough - and then there is a maven plugin for that, no? BTW: I thought we agreed on a structure like myfaces-jsfcommons-converters myfaces-jsfcommons-validators ... Also overly complex, but something I can learn to understand Lets reiterate: I prefer to start with a simple jsfcommons project where we have no faces-config.xml (at least not in a place where JSF loads it automatically). Providing a jsfcommons-faces-config.xml which the user has to add to the configuration will avoid any side-effect when dropping in our jsfcommons jar. It also allows to selectively active things as the users can change their own configuration as required. Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox for myfaces land at all. Lets promote the tomahawk-sandbox one level higher - thats it. Ciao, Mario
Re: [orchestra] Conversation issues with master-detail
Hi! I am trying to create a master-detail screen scenario and am following the best-practices guide in the wiki (the simple CRUD cycle - http://wiki.apache.org/myfaces/A_simple_Crud_Cycle) and it does not actually work. Am I doing something wrong? Unhappily the author of this page did not say which scope to use for the master and detail view. @Werner, can you comment on it please. When I do a save on the DetailView, if I call refreshList on the MasterView after saving using the DetailView instance of the BO, the list does NOT contain my changes. I understand why this is happening. The BO in the MasterView has its own entity manager as it is in a different conversation than the DetailView. It does not help to do Conversation.getCurrentInstance().invalidate() in the DetailView before doing a list refresh on the master view as there is still nothing to force the entity manager in the MasterView to dump its cached objects. Yep, this invalidate will just invalidate the detail conversation, not the one of the Master. Some possible ways are: 1) If Master and Detail are both in two different conversations (flash) simply avoid referencing the Master from your Detail. When navigating to the Detail this will end the Master conversation automatically, on navigating back the Master will be a fresh instance with a fresh EntityManager ... thus, should load the data again. 2) End the Master conversation from within the Detail bean (not recommended) ConversationUtils.invalidateIfExists(name of master conversation). Name of name of master conversation is the one you configured using orchestra:conversationName on the bean definition or the bean-name if you didn't use that configuration. 3) Use the same conversation for the Master and Detail. Do this by using the orchestra:conversationName=editXYZData on both bean definitions. Then they use the same EntityManager and you are fine anyway. Putting both in the flash scope will handle the cleanup once the user navigates away. This is the way I'll mostly use. As a side note, if the Master page allows to define some filter, I often put them into their own bean in a separate conversation of type manual. That way, even if the flash conversation ends the user input won't be lost. For sure, this filter bean should not hold any entity as you might run into problems if passing entities from one conversation to another one. Hope this helps! Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Hi! well, when we put in the converters/validators, we will also have faces-cfg for them... Yep, if we have separate projects we can have the faces-config.xml again. Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox for myfaces land at all. Lets promote the tomahawk-sandbox one level higher - thats it. +1 no sandbox inside the master project. Just to clarify, this means a -1 to my suggestion above, no? For Trinidad Sandbox, I am planing to create it at the same level, where projects like tomahawk, trinidad or portlet-bridge are Hmm and this again means to be a +1 to my suggestion ... I am confused now ;-) If you create it at the project level (which I proposed), why not simply move the tomahawk-sandbox up? Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Hi Manfred! Oh no! Seems like we are going round in circles... :-( Seems like. A mail (31.10.2007 21:59) from you And don't forget about all those (renderkit-independent!) converters and validators. People might argue for putting them into a jsfcommons components artifact. What about the Joda converter that Matthias suggested? What is the reason it should go into Trinidad? It is not renderkit-specific or somehow related to Trinidad. So, a perfect candidate for jsfcommons-components, right? (There would even be place for a separate jsfcommons-converters artifacts, IMHO) Do we really want component like stuff like converters and validators there? Didn't we discuss this already? Having projects like jsfcommons-utils and jsfcommons-components were suggested by you. But true, I lost the focus now :-( I really thought that stuff like NavigationHandler (not configured) would go into the jsfcommons too. Seems like I am wrong. Sorry! Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Hi! If we need jar supporting component-developer we should stop the repackaging of shared, create a shared.jar and add the dependency instead to impl and tomahwak. Oh ... how much I'd love this to happen Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Hi! that would easy the debugging as well. why? If you have both sources for api and impl jar in your IDE there is no difference. It IS. You have to know at which class to set a breakpoint. Even if you see a shared class, you have to set the breakpoint to the refactored shared_tomahawk, shared_impl, etc. Depending on which lib you are going to debug. Currently this also requires you to know which version you are going to debug as e.g. Tomahawk uses the shared from the 1.1 trunk while the 1.2 trunk has its own shared. I already spent a significat amount of time during debugging until I figured out that fact. Also, if you change something in shared you have to run maven ... you know why ;-) I don't see any reason why we shoulnd't being able to provide a stable api even for shared. Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Hi! Mario Ivankovits [EMAIL PROTECTED] schrieb: I don't see any reason why we shoulnd't being able to provide a stable api even for shared. I have to strongly disagree here. I know what all this means, but, this statement, and what Manfred wrote means, that MyFaces is not allowed to depend on jsfcommons and is not allowed to use all the nice utility methods in there. I still think it should be possible to provide a library with a stable api over time, new methods can be added without breaking backward compatibility. See commons-lang. IF JSF changes in a way that makes this no longer possible, we could create a new package structure for the new API. Something like org.apache.myfaces.jsfcommons - org.apache.myfaces.jsfcommons2 etc. Dropping such a jar into the J2EE Container does not necessarily break anything. BTW: I think all this J2EE stuff with providing implementations is broken, at least, it shows a major caveat in Java where a library is not able to define on which other library-version it depends on. A shame that this has not been fixed for a long time ... Something like this is planned in Java 1.7 I think, no? In any case, I think having a subject-separated project structure in jsfcommons is better than the api/impl way. However, if we split tomahawk into pieces and providing a jsfcommons for just the utils thing I am fine too. Yep, maybe this is the way how tomahawk should evolve and it frees jsfcommons from the discussion if converters/validators should be put in there - the answer then is simply NO, put it into tomahawk-converters. In the sense of equality we should find an all new name for this project which has nothing to do with commons, tomahawk, trinidad etc. Ciao, Mario
Re: Tomcat or Geronimo ?
Hi! Hopefully JSF2.0 will have a better managed bean (IOC) system defined. Or that they will drop that part of the spec completely, and just recommend that an external one be used. due to the lack of openness, we'll get a surprise :-) If Sun would recommend to use Spring ... now THAT would be a surprise ... :-) Ciao, Mario
Re: Future Focus Question: Tomahawk or Trinidad
Hi! I am afraid that Tomahawk could be a showstopper for a migration from myFaces 1.1.5 to 1.2.1. I use tomahawk here with MyFaces 1.2.x-head (with facelets). No real problems here so far. Ciao, Mario
Re: Future Focus Question: Tomahawk or Trinidad
Hi! -- Then I'm sure you're not working with the combo MF1.2 + Facelets + Tomahawk 2.0 because that's a joke. Even selectOneMenu's don't work properly. (have a look at the posted bugs) Dont know what Tomahawk 2.0 is, but this is the list of libraries we use (-dev means they are home-made snapshots): # ls -l *tom* *face* -rw-rw-r-- 1 im LINPDC+domain users 300600 19. Okt 08:50 jsf-facelets-1.1.13.jar -rw-rw-r-- 1 im LINPDC+domain users 322211 15. Nov 16:57 myfaces-api-1.2.1-dev.jar -rw-rw-r-- 1 im LINPDC+domain users 699188 15. Nov 16:57 myfaces-impl-1.2.1-dev.jar -rw-rw-r-- 1 im LINPDC+domain users 344329 27. Nov 08:55 myfaces-orchestra-core-1.1-dev.jar -rw-rw-r-- 1 im LINPDC+domain users 125494 15. Nov 16:57 myfaces-orchestra-core15-1.0-dev.jar -rw-rw-r-- 1 im LINPDC+domain users 18862 15. Nov 16:57 myfaces-orchestra-sandbox-1.0-dev.jar -rw-rw-r-- 1 im LINPDC+domain users 2962767 15. Nov 16:57 tomahawk-1.1.7-dev.jar -rw-rw-r-- 1 im LINPDC+domain users 646879 15. Nov 16:57 tomahawk-sandbox-1.1.7-dev.jar -rw-rw-r-- 1 im LINPDC+domain users 104081 15. Nov 16:57 tomahawk-sandbox15-1.1.7-dev.jar We are going into production with this Ciao, Mario
Re: Tomahawk ExtensionsFilter, Trinidad skinning (and Tobago)
Hi! the solution is far from perfect. For me, every solution requiring buffering is far from perfect. With JSF 1.1 nothing else worked except like the StreamingAddResource or DojoAddResource, but they have their own drawbacks. For JSF1.2 this is why I suggested in another thread to introduce something like a ResourceInfoProvider interface which a renderer has to implement and then, after creating the view and before actual rendering scan the tree and ask every component about the resources it requires. Then, with the help of specific component we can render the stylesheet,script, etc stuff without buffering. Ciao, Mario
Re: Rendering amp; instead of for href attribute
Hi! So, I propose to always render amp; as it is recommended in the W3C HTML Spec. I'd propose to make it configureable out of the box, a simple context-param with default to amp; - easy enough and will survive the users from providing their own LinkRenderer. Something like: org.apache.myfaces.STRICT_XHTML_LINKS=true|false - default=true Ciao, Mario
Re: [vdr] Whats next? [was: Re: next features?]
Hi! I am using the xine-xxmc plugin and cle266 hw decoder for some years now; video running smoothly and cpu usage is low. vdr is running with vdr-xine, but I don't see why you could not use xxmc also with xineliboutput... Interesting. Do you use the TV-Out or VGA? The quality should be better with VGA, but: What resolution did you setup to get full-screen tv output in the right aspect ratio? What about deinterlacing? I now own a 100Hz LCD-TV (Sony KDL-32D3000), but it looks like the tricks used in there won't work with PC input as then you'll see the typical kamm-effekt (comb-effect ;-) !?) again. It looks like the PC has to do the work then. What about the various video formats? If we can't send the streams in their native format we no longer can use all the aspect settings of the TV, no? All the resizing will be done by xine now. Or is there a way that xine changes the output format on the fly? Ciao, Mario ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: JSF Performance
Hi! On 11/15/07, *Andrew Robinson* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: It seems like, for the most part, tomahawk is a dead project (no releases for a long time, no promotion of the sandbox to the core tomahawk project in a long time, etc.). I am still VERY happy with tomhawk, many things I'd like to have from other libs are solvable with the PPR stuff (which only needs some minor enhancements for my day-work) I am looking forward for oracle-rich-client-donation we might get, though. Hopefully Trinidad will swallow Tomahawk in the near future and we can be done with the ExtensionsFilter. I am not sure how Trinidad solve this problem without buffering the response. Even if they buffer the repsonse in their documentHead tag or something like this ... they buffer which I count equally bad. With or without ExtensionsFilter. In contrast we provide two additional AddResource provider - StreamingAddResource and DojoAddResource (which will be renamed anytime soon). Both do not require the ExtensionsFilter for intercepting the output nor do they require buffering. DojoAddResource is one of our last sandbox tries ... so I'd say we are still active Hopefully Trinidad can catch up in the near future ;-) Ciao, Mario
Re: [OFFTOPIC] Hackathon
Hi! we'll do a MyFaces Hackathon in Vienna - from December 14th to 16th. Looks like I'll be there on Friday 14th and Saturday 15th. And, well, Apple-Juice for me please, I do not drink any alcohol .. What about a WIKI page where we collect what to Hack-A-Ton? I have an idea for the PPR stuff which should be doable. Ciao, Mario
ppr and secondaryIds/messages [was: Re: [OFFTOPIC] Hackathon]
Hi! And, well, Apple-Juice for me please, I do not drink any alcohol .. ...since...? Any bad experiences you have made recently? :) Hmmm can't remember ;-) Yes, a wiki page for collecting the todos sounds like a good idea. If you mean the message stuff for ppr, this is also on my list for enhancing ppr. Yep! I generalized (I think) my idea further. I thought about something like secondaryIds, which means: If this PPR is going to be re-fetched, also re-fetch all components (outside of this PPR) with the given Id(s). Luckily this will point to a message component, but any other component will make it too. Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Hi! BTW, I do not understand why some of you are so scared by multiple jsfcommons artifacts. I see it being much work to maintain ... but anyway, since you are the one who is going to do the initial maven work :-) I do no longer argue against. So, can we start now ;-) ? Ciao, Mario
Re: [ORCHESTRA] Spring-Webflow
Hi! I've just heard that Spring-Webflow will add JPA-support in the next release. We should dress warmer here ;) Yes, I already know that. Well, competition is always good ;-) I see: 1) JBoss Seam, which might be very feature-full but which is also very intrusive to your application and requires you to use a new programming model. BTW: I think Seam should be split into various modules, for example, the ability to being able to have function calls with method parameters in Facelets would be great to be usable without seam. 2) Web-Beans: ditto 3) Spring-Webflow, which might be a little less intrusive, but requires you to use a configuration to describe the webflow, doesn't it? 4) Orchestra, which is a very thin layer and nicely integrates into your application, even a complex legacy one. The automatic conversation starting with the ability to have some in parallel makes it VERY easy to use. Ciao, Mario
Re: [ORCHESTRA] Spring-Webflow
Hi! I am not sure if I talk about the same, but In Orchestra it is all about beans. What would be nice is, if we could define a page-flow (state A) having it's own set of beans and being able to enter the page-flow (state B) again and having a new set of beans then (effectively the same bean/el names but the views will see different instances). Once state B finished state A will be reactivated again. Is this what we would like to have? For this, we need an additional configuration on the conversation ... maybe a start to have a conversation configuration at all: conversation name=conversationA group=orderState / conversation name=conversationB group=orderState / Now, with a simple API (for now) ConversationManager.getInstance().interruptState(orderState); ConversationManager.getInstance().invalidateState(String) ConversationManager.getInstance().resumeState(String) ListString states = ConversationManager.getInstance().getInterruptedStates(orderState); The idea is to group conversations together and then to allow to interrupt/resume this group of conversations. Or did I understand something wrong? Ciao, Mario
Re: [Orchestra] Conversation
Hi! flash is somewhat confusing to persons that know rails... Should we change the name(s)? manualConversation flashConversation AFAIR in the documentation we already talk about conversation.manual and conversation.flash. Ciao, Mario
Re: [Orchestra] Conversation
Matthias Wessendorf schrieb: yes, but the term flash is used there differently, from what I heard. So then, what is an appropriate term in the JSF world? --- Mario
Re: New wiki ? (was Re: [site] new pages ?)
Hi! Do we want to migrate to the cwiki, that some Apache projects are using ? I don't like to use a commercial product for open-source development. In fact, this also counts for JIRA, but this decision has been felt. Ciao, Mario
Re: New wiki ? (was Re: [site] new pages ?)
Do we want to migrate to the cwiki, that some Apache projects are using ? I don't like to use a commercial product for open-source development. In fact, this also counts for JIRA, but this decision has been felt. ... except for my IDE where I didn't manage to be as productive with one of the open-source one ;-) I am not sure if cwiki allows us to increase our productivity ... if it does my argumentations stands small :-) Ciao, Mario
Re: [commons] Joda support ?
Hi! What are the thoughts about providing a Joda DateTime converter in the upcoming commons project ? BTW, we use Joda here for a long time, so I have something to contribute Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Hi! I have a suggestion that would solve this (and the naming as well): Let's start a new MLP* called MyFaces JSF Commons which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components For the artifact names I propose: myfaces-jsfcommons-utils and myfaces-jsfcommons-components I think this makes stuff again too complicated to be maintained in the future. You have two additional projects/modules, with maybe separate release cycles - and even if not, you have to release them both at the same time. Documentation and site is splitted, pom work is required to do twice, etc My preference is to stick with just one MyFaces JSF Commons project - artifactIdmyfaces-jsfcommons/artifactId Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Hi! which is itself an umbrella project for two artifacts** called MyFaces JSF Commons Utils and MyFaces JSF Commons Components I suggest that I prepare an initial setup, and check it in, so that there is some concrete stuff we can talk about. Ok? I still don't get why we should increase the number of modules here. Two artifacts means two jars, no? And then, what is a Component? I think we agreed that we just want to add render-less components, no? Else it has to go into tomahawk. The Commons should not be just a component-library without (the dreaded) shared. Is a UrlNavigationHandler a Component then or a util? It has no component yet, but what if it has one in the future? I know, we then can simply just add this component to the Components, but why should we split the stuff? In this case I'd have a org.apache.myfaces.commons.urlNavigationHandler package where everything lives in. org.apache.myfaces.commons.urlNavigationHandler (the api) org.apache.myfaces.commons.urlNavigationHandler.impl org.apache.myfaces.commons.urlNavigationHandler.component etc Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
To avoid this I'd NOT include eg viewhandler or navigation handler in the jar. Taglib wont harm if not used. Instead we just document how to setup. Mario -Original Message- From: Manfred Geiler [EMAIL PROTECTED] Date: Wednesday, Okt 31, 2007 4:53 pm Subject: Re: [result][vote] start up the MyFaces Commons project To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces Development dev@myfaces.apache.org On 10/31/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! which is itself an 'umbrella' project for two artifacts** called 'MyFaces JSF Commons Utils' and 'MyFaces JSF Commons Components' I suggest that I prepare an initial setup, and check it in, so that there is some concrete stuff we can talk about. Ok? I still don't get why we should increase the number of modules here. Two artifacts means two jars, no? Yes, sure. And then, what is a Component? I think we agreed that we just want to add render-less components, no? Else it has to go into tomahawk. The Commons should not be just a 'component-library without (the dreaded) shared'. Is a UrlNavigationHandler a Component then or a util? It has no component yet, but what if it has one in the future? I know, we then can simply just add this component to the Components, but why should we split the stuff? In this case I'd have a org.apache.myfaces.commons.urlNavigationHandler package where everything lives in. org.apache.myfaces.commons.urlNavigationHandler (the api) org.apache.myfaces.commons.urlNavigationHandler.impl org.apache.myfaces.commons.urlNavigationHandler.component etc Also renderkit independent 'components' need a taglib in the META-INF dir. This is the main difference between a 'component' and a goodie class a user can decide to use or not. --Manfred
Re: Locking a webapp against parallel using
Hi! Is it possible to describe full attribute optimistic locking in a couple of sentences, or should I look at the cayenne docs? (A quick google didn't show anything obviously related..) Sure. Instead of creating and locking on a special version field, lock on all fields (or all that are important).Assuming table foo[w,x,y,z], use update foo set x=1, y=1 where w=old_w, x=old_x, y=old_y, z=old_z Beware, (especially with the or all that are important thing) this might allow to become your entity out of sync. Means, your entity is a mixture of different updates which you are not aware of then. Using all properties of the version column (which might be more performant) is the only option to prevent this. Ciao, Mario
Re: [OT] Re: Locking a webapp against parallel using
Mike Kienenberger schrieb: Beware, (especially with the or all that are important thing) this might allow to become your entity out of sync. Means, your entity is a mixture of Well, we're getting a bit off topic, but there's nothing to beware of here. If you lock on all columns which can change, Thats why I wrote especially with the or all that are important thing :-) Ciao, Mario
Re: [Trinidad] inputFile - upload empty files ?
Matthias Wessendorf schrieb: tr:validateUploadedFile / might be the better name. I am very happy with this! Though, should go to the upcoming commons project, shouldn't it? Ciao, Mario -M On 10/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: So, why not doing a tr:validateFileLength / with the following attributes: -minLength -maxLength -contentType Greetings, Matthias On 10/29/07, Andrew Robinson [EMAIL PROTECTED] wrote: Would a tr:validateFileLength min=1 / be more useful? Then min and max could be used. -A On 10/29/07, Manfred Geiler [EMAIL PROTECTED] wrote: Matze, What about providing a standard tr:validateNonEmptyFile Vaidator. This would make everybody happy, right? lg, Manfred On 10/29/07, Andrew Robinson [EMAIL PROTECTED] wrote: Strong -1 on this 0 byte files are very valid, especially on a unix based platform. There are many times that a file by its existence implies meaning. Take for example ~/.config/xserver-xgl/disable, if this file is present, xgl mode of the linux X server is disabled for that user. The file should be empty. This is just one small example. If an application doesn't want to support 0 byte files, it should use a validator or actionListener method to check the length. -Andrew On 10/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, currently Trinidad's inputFile allows the upload of an empty file (0 bytes). I think it shouldn't. When an inputFile object is marked as required, I would expect that a user does a real upload, and not a fake upload. Sure, an app-dev could write a validation method, but I think 0-byte is somewhat equal to not submitted. WDYT ? -M -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
[myfaces1.2] spec question about Application.createConverter
Hi! Currently, if you call Application.createConverter with a non-existent converterId a NullPointerException:675 will be thrown. Is this required by the spec or do you mind if I change this to a throw new FacesException(No converter with id + converterId + found, e); Ciao, Mario
[jira] Created: (MYFACES-1755) create converter with unknown id fails with NPE
create converter with unknown id fails with NPE --- Key: MYFACES-1755 URL: https://issues.apache.org/jira/browse/MYFACES-1755 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0 Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 1.2.1-SNAPSHOT see summary -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1755) create converter with unknown id fails with NPE
[ https://issues.apache.org/jira/browse/MYFACES-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivankovits resolved MYFACES-1755. --- Resolution: Fixed create converter with unknown id fails with NPE --- Key: MYFACES-1755 URL: https://issues.apache.org/jira/browse/MYFACES-1755 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0 Reporter: Mario Ivankovits Assignee: Mario Ivankovits Fix For: 1.2.1-SNAPSHOT see summary -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [result][vote] start up the MyFaces Commons project
Hi! I am not sure why we can't call it simply MyFaces Commons? I think the name is pretty fine. But to put something additional into the fire: MyFaces Essentials, or, to move on with islands, MyFaces Papeete Ciao, Mario Pretty hard to discuss for non-Americans, I can't speak for Manfred, but I accepted the discussions, said OK and moved forward. -M On 10/30/07, Andrew Robinson [EMAIL PROTECTED] wrote: Unless the code is really bad, is it really derogatory at all? Apache is a native American name, so projects using that theme go well. I'm not aware of the other discussions, but I did come from a school that had to change its name because of non-native Americans complaining about native American rights and know the gist. Why would Native Americans be offended by their own tribe and location names? If anything it keeps people thinking of their people group and their culture which should be viewed as a good thing, I would hope. On 10/30/07, Manfred Geiler [EMAIL PROTECTED] wrote: Oh no! Not that discussion again... :-( Ron, you might not be aware of former discussions on this list - not your fault of course. Yes, there are many ASF projects which have names related to Native Americans, BUT there are also many people concerned that those names could be offensive to Native Americans. And MyFaces is - of course - not the only ASF project where such discussions took place: see [1] to get an idea about such discussions in the Geronimo community. BTW, did you know they once had Tomahawk in their list of suggest alternatives? ;-) Don't get me wrong, my personal opinion is +/-0 for names related to Native Americans Just wanted to sensitize. --Manfred [1] http://cwiki.apache.org/GMOxSBOX/why-apache-geronimo.html On 10/30/07, Ron Smits [EMAIL PROTECTED] wrote: How about Tsalagi? that is the name of the cherokee language On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! How about a new ASF style name instead of basic, commons or something else that could be more easily misconstrued? Could you give an ASF style name for example? --- Mario -- I reject your reality and substitute my own --- Adam Savage, the mythbusters -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: [Tomahawk] Tiles2
Hi! If we can put Tiles2 dependencies into Tomahawk, why not put facelets code directly into Tomahawk? I think we should refactor the sandbox (move it out of tomahawk). One Sandbox for the whole MyFaces community might be enough, no? Said that, you can put the Tiles2 into the sandbox, but later on, if it is still maintained/in use, move it to a MyFaces Tiles2 project. The more we put into tomhawk, the more it is likely that it conflicts with something else - we end up with negative feedback not only from the JBoss Seam guys, probably. Ciao, Mario On 10/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: If nobody care, I'll put it into sandbox. Thx, Matthias On 10/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, regarding TOMAHAWK-1115 ([1]), do we want to support it inside of Tomahawk, or the sandbox ? -Matthias [1] https://issues.apache.org/jira/browse/TOMAHAWK-1115 -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: [result][vote] start up the MyFaces Commons project
Hi! 2. Following some old discussion, we don't know if extra components libaries are going to stay as MyFaces subprojects forever. For instance, when RCF get out of incubation, it might be strange to have a subsubproject of MyFaces since RCF is a subproject of Trinidad. If we can get a nice modular infrastructure including only renderkit independent at first, but then adding some optional module for PPR, skinning and such, then we could move to a TLP and have Tomahawk, Tobago, Trinidad and RCF be simple subprojects all depending only on that new common library. Hopefully, it would also ensure perfect interoperability between all of them at the same time. I have no plans to ever move TLP with anything I do here in MyFaces land, I feel very comfortable under the MyFaces umbrella and I also do not understand (yet) why we should leave. MyFaces = [EMAIL PROTECTED] - IMHO that should be the direction. Maybe we have to split the ML later on, but that is another story. Ciao, Mario
Re: [result][vote] start up the MyFaces Commons project
Yep, KIFS - Keep It Flat and Simple. For the same reason we should not put the Facelets project under tomahawk - even though it may have tomahawk in its name. With the projects names Manfred proposed this is easily possible. Ciao, Mario Scott O'Bryan schrieb: Yeah, and I don't know what's going to happen with the RCF project, guess it's up to the community to decide, but I don't see why it needs to be a subproject of Trinidad so much as a subproject of MyFaces with a dependency on Trinidad. :) Most all of it's dependencies are on API packages in Trinidad and I imagine that any impl dependencies would have to be resolved anyway. Scott Mario Ivankovits wrote: Hi! 2. Following some old discussion, we don't know if extra components libaries are going to stay as MyFaces subprojects forever. For instance, when RCF get out of incubation, it might be strange to have a subsubproject of MyFaces since RCF is a subproject of Trinidad. If we can get a nice modular infrastructure including only renderkit independent at first, but then adding some optional module for PPR, skinning and such, then we could move to a TLP and have Tomahawk, Tobago, Trinidad and RCF be simple subprojects all depending only on that new common library. Hopefully, it would also ensure perfect interoperability between all of them at the same time. I have no plans to ever move TLP with anything I do here in MyFaces land, I feel very comfortable under the MyFaces umbrella and I also do not understand (yet) why we should leave. MyFaces = [EMAIL PROTECTED] - IMHO that should be the direction. Maybe we have to split the ML later on, but that is another story. Ciao, Mario
Re: [Orchestra] TODO in UrlParameterNavigationHandler
Hi!
// TODO: this only supports one EL expression at the moment; it would
be nice
// to support multiple.
I do not exactly know why we stated that.
In fact, the TODO should be:
// TODO: Parse every #{} one by one, correctly convert it to a string
(e.g. by using converters) and url encode them in the correct charset.
what i am doin is right???
Yep, everything is fine!
We will fix the new TODO sometimes soon I hope ...
Ciao,
Mario
Re: [Trinidad] Dialog - DialogRequest.java
Hi Matthias! but Orchestra expects a conversationContext param in that URL, like /__ADFv__.xhtml?_afPfm=5c4a2651_t=fred_vir=/gmap/map.xhtmlloc=enconversationContext=1 Doing this as well: context.getExternalContext().encodeActionURL(theUrlWeCreated); I don't know anything about Trinidad, but I am pretty sure it is save to add this encoding, else, the windowing stuff will fail with cookies-only environments as then the ;jsessionid= is missing too. Ciao, Mario
Re: Redirect to URL with param from navigation-case
Hi!
navigation-case
from-outcomeadded/from-outcome
to-view-id/view.jsf?myParam=#{myManagedBean.id}/to-view-id
redirect/
Have a look at MyFaces-Orchestra. Especially at urlParamNav package [1]
to get an idea how this can be done.
I hope we can provide an implementation without Orchestra in the
upcoming MyFaces Commons project soon.
Ciao,
Mario
[1]
http://svn.apache.org/viewvc/myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/urlParamNav/
Re: myfaces12: build failure - isViewStateJavascript
Hi! MyFaces 1.2.1-SNAPSHOT builds properly on my computer - I am also using /current12. Wonder what this is about... Mario, you are on the latest sources as well? Yep I didn't meant that I have this problem too, just wanted to point out that checking out current12 will do the trick for Simon too. Ciao, Mario
Re: [vote] start up the MyFaces Commons project
Hi! 1. Clear separation of API and IMPL (at least on package level, better Shouldn't it be possible to have a stable API even without separating it out? Have a look at http://commons.apache.org/beanutils/apidocs/org/apache/commons/beanutils/BeanUtils.html for an example how static utils CAN be clearly separated into api and impl. I am not sure if this is the best possible example ;-) The reason they splitted these classes semms to be that the implementation is stateful. Means, they cache stuff on ClassLoader level (ContextClassLoaderLocal) and therefore they need an instance to hold the datastructure instead of just simple utility methods. In our case we might just end up with the delegator pattern, which seems to be overly complex, doesn't it? 2. Let's start to name svn folders the same as the artifacts. This /home/im/projects/myfaces12/commons/myfaces-commons/myfaces-commons-api/src/main/java /home/im/projects/myfaces12/commons/myfaces-commons/myfaces-commons-impl/src/main/java I think the middle part is overly redundant. It's simply faster to scan only the leaves of your folder tree structure than to scan structurally: Ok, here is the folder 'api' - hmm which api? snip/ Nice story, you saved my day :-) Ok, so lets try it that way if no one else has a better argument against. Ciao, Mario
Re: [Trinidad] inputFile - upload empty files ?
Hi! Sure, an app-dev could write a validation method, but I think 0-byte is somewhat equal to not submitted. I don't think so. A 0-byte file is a valid file (might be a flag-file to trigger something). If you treat a 0-byte file as fake, what would you do with files with just one space. I think a validator is the correct way to deal with, having a minFileSize=, or contentMimeType= etc. Ciao, Mario
[result][vote] start up the MyFaces Commons project
Hi! The result of the vote is: +1 Mike Kienenberger Martin Marinschek Matthias Wessendorf Volker Weber Gary VanMatre Grant Smith Cagaty Civici Paul Spencer Scott O'Bryan Ernst Fastl alvaro tovar (even if he don't know why ;-) ) Manfred Geiler Bernd Bohmann Ron Smits I've abstaind from splitting binding and non binding votes as everyone can see that this vote passed with amazing attendance. Seems like there is some maven work waiting now :-) Ciao, Mario
Re: [vote] start up a MyFaces Facelets project
Mario Ivankovits schrieb: +1 Hi! Lets start up a MyFaces Facelets project. A name needs to be found. The aim of this project will be to contain: 1) the taglibs for tomahawk and tomahawk-sandbox as long as we have the generator not running again. I'd like to ask Bruno if we can jump-start with his google project 2) everything which is directly related to stuff which only works with Facelets, being that components or whatever. [ ] +1 yea, lets start [ ] +0 [ ] -1 no, for those reasons . I'll do the maven work then (a not very sophisticated one, just copy it from another of our modules) I am not sure if we collect enough substance for this project to survive, but time will tell. Ciao, Mario -- mit freundlichen Grüßen Mario Ivankovits Software Engineering OPS EDV VertriebsgesmbH A-1120 Wien, Michael-Bernhard-Gasse 10 Firmenbuch Nr.: FN51233v, Handelsgericht Wien Tel.: +43-1-8938810; Fax: +43-1-8938810/3700 http://www.ops.co.at E-Mail: [EMAIL PROTECTED] Skype: mario_ivankovits
Re: [Trinidad] inputFile - upload empty files ?
Hi! Technically the answer is no for both questions. Well the pragmatical (and only reasonable) answer to the second question is yes in the JSF spec (comp. required for h:inputText). Therefore it makes sense to say yes to Q1 as well. I think the difference here is, that if there was a file uploaded the user HAD provide a file by using the file-selector or entered a path. Means, the user made an action to upload a file - regarding to required this condition has been fulfilled. If the application needs something more than a zero byte file this is on their responsibility then. In contrast to the string ... you can't enter an empty string. Ciao, Mario
