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
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
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-
,
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
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
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
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
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
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)
Hi Simon!
public void serveResource(ServletContext context, HttpServletRequest
request,
-HttpServletResponse response, String resourceUri) throws
IOException;
+HttpServletResponse response, String resourceUri)
+throws IOException, ClosedSocketException;
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
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
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
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
Hi Simon!
Are there any objections?
Sounds good!
Ciao,
Mario
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
Hi!
The Myfaces PMC is proud to announce a new addition to our community.
Please welcome Bernhard Huemer as the newest MyFaces committer.
Welcome Bernhard !
---
Mario
Ciao,
Mario
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
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
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
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
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
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
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
Matt Tyson schrieb:
I've got a Tree component that handles node expansions via Ajax. What do you
think the interest would be in having this donated to Tomahawk?
I'd say: Yes!
Is it an all new component or did you enhance tree2?
If you could open a jira ticket and add a patch so that we
Hi Matt!
welcome tree3;
Matthias is right. What are the differences to the existing tree2 component?
Having tree2 enhanced to do ajaxed-node-fetching would greatly increase
the chance that your patch will be accepted. We really would like to
avoid to introduce yet another tree. Do
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
Hi!
Sounds good - can you send your example again utilizing the
detailStamp approach if that fits?
So, not it is getting stressy again. I have a bad need for it now.
So, using the detailStamp approach it might look like:
t:datable var=group1 value=#{bean.data}
...
t:column colspan=10
Hi!
Would one mind if I add these two new attributes to the t:column tag?
Yes
Okay
RowID already exists on t:table
Oh - great. Might work, just, that it is that weird implemented that it
wont work with facelets.
Anyone has some informations why the tag handler uses
Hi!
It so happens, I have been looking for this sort of a solution.
:-) Yea, I wonder why no one else have had a need for this too. It is a
common use-case in our application.
In my case, I have a table with three columns, with three headings.
snip /
Do you mean something like this:
Hi!
Would one mind if I add these two new attributes to the t:column tag?
rowId should go to the tr element and colId to the th element. As usual,
the row index will be added to the rowId and the thing should follow the
default getClientId semantic. (parent namespaces etc)
I need this
Hi!
The rowId on the t:datatable is rendered without namespace. Following
this fact I've added a columnId to the t:column which will be rendered
without namespace also.
While I know that this is crap, I just have done it that way to be
consistent in this area.
However, my better half ;-) told
Hi!
Being on vacation it is hard to follow the actual discussions, so, sorry
if I missed something along the lines.
While the fact that Leonardo flipped the object hierarchy can be treated
as genious idea (kudos!), I am not fully convinced that this is what we
want in the end.
Please, let me
Hi!
It *is* useful to be able to create converters that have access to
conversation scopes, which in turn mean they need to be instantiated by
pulling them from Spring. But this syntax is already supported by jsf:
someComponent id=comp2 converter=#{convId}/
I don't think so. Isnt it that the
Hi!
Nice to see you back!
Hehe - Thanks! Yea, and in after-ski-mode now ;-)
Nope. The EL expression returns a Converter instance
ah - wasn't aware from top of my head.
Ok, so probably the ony thing we have to take a look at is how those converters
work installed as child of a component using
Hi!
Go on, rub it in .. I've been spending all my spare time working on an
Orchestra release :-)
That's fun too, isn't it ;-)
If we find a way how these could work I wouldn't mind if we get rid of the
current solution.
Your wish is my command.
When thinking about it, this one wasn't
, 2008 9:08 am
Subject: Re: [orchestra] conversation-scoped converters
To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces
Development dev@myfaces.apache.org
On Sun, 2008-02-17 at 08:16 +0100, Mario Ivankovits wrote:
If we find a way how these could work I wouldn't mind if we get
Hi!
But there is a third way of configuring a converter.
This is configuring a converter with its own tag, like dateTimeConverter.
This allows you to configure this very instance of the converter.
We don't need to support pulling f:dateTimeConverter instances from
Spring do we? Those
Hi!
public interface AjaxTreeDataProvider {
public List getRootNodes();
public List getChildNodes(String nodeString);
}
Shouldn't this be something like this:
public interface AjaxTreeDataProvider {
public List getRootNodes();
public List getChildNodes(Object node);
Hi!
2) release of orchestra-core15-1.0
We're working on it, but there's quite a lot of effort still needed. It
all works (and is being used in production) but needs a lot of polishing
before a stable API can be declared. Probably a couple of months away..
Really months? What do
Hi!
Is there any reason that the MyFaces command link is rendered with
href=# and onlclick=return xxx() instead of href=javascript: ?
It seems, the latter will make the open link in new window feature of
some browsers stopping to work. Which is what I'd like to have.
What do you think about
Hi!
Why do you say that some browsers can't open the link in a new window?
No, I do not think that this is what I said, at least, I didn't wanted
to say that.
You probably know the right mouse click/open link in new window
function of the browsers?
You probably also know that this is a major
--
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
Versions: 1.0.14
Reporter: Bernd Bohmann
Assignee: Bernd Bohmann
Priority: Minor
Fix For: 1.0.15, 1.1.0
--
mit freundlichen Grüßen
Mario Ivankovits
Software Engineering
OPS EDV VertriebsgesmbH
A-1120 Wien, Michael
Hi!
Is there any reason that the MyFaces command link is rendered with
href=# and onlclick=return xxx() instead of href=javascript: ?
It seems to me the right thing to do is to simply change the href=# to
href=javascript:void(0).
I think we can do that, no?
Ciao,
Mario
Hi!
+1 very good idea!
Are those +1 due to the fact that you think that Orchestra is not the
best place where such a component is located (which I understood), or is
it that this component is still missunderstood ( :-( ) ?
Fact is, that this component is a great timesaver when it comes to
Hi!
The tar.gz and zip archives are deployed at [3]
LICENSE.txt and NOTICE.txt are missing from, at least, the tar.gz archive.
+1 when fixed.
Not so important, but, it looks like these archives are a mixture of
-bin and -src (which is fine I think), but no class files beside the jar
are in
Gratulation Simon. Great work :-)
Mario
-Original Message-
From: simon [EMAIL PROTECTED]
Date: Wednesday, Mär 12, 2008 8:00 am
Subject: announcement: Orchestra Core 1.1 released
To: Reply-MyFaces Discussion [EMAIL PROTECTED]To: MyFaces Discussion
[EMAIL PROTECTED]
The Apache
Hi!
Hi, I like the approach. I am not very keen in annotated javadocs
(which is error prone IMO) but that is just fine and I would say a
better alternative to the XMLs (which are rather error prone too).
However, it would be nice to have the builder library generic enough
so we could use
Hi!
I have the need to do a partial model update for given components on ppr
submit. (subform won't work here)
I have a form with a couple of input fields, lets say FIELD_A, FIELD_B,
FIELD_C, FIELD_D - all in one form.
FIELD_A is required
now, after something has been entered in FIELD_B,
Hi!
The pprSubmit is something like a generic autoSubmit feature for
command components (see also autoSubmit attribute in trinidad).
? pprSubmit does nothing else than rendering the javascript to hook on
the new components too, no?
I do not understand what you mean with autoSubmit here.
Hi!
Something which happend to me too multiple times too, though, it is
really hard to read a commit if it comes with a reformat of the source too.
So, please: Before starting work on a source reformat it and commit this
reformat only!
Links to the code format settings can be found here [1] -
Hi!
I have a build failure here as the site module can't find the 6-SNAPSHOT
version of the (master?) pom.
parent
groupIdorg.apache.myfaces/groupId
artifactIdmyfaces/artifactId
version6-SNAPSHOT/version
/parent
If I change this back to version 5 it works.
Do one know
Hi!
The complicated thing is, that the pprSubmit enhancement would require a
custom LifeCycle for PPR requests (why is it a PhaseListener by now?)
I am investigating some time into that.
In fact, the thing missing now is invokeOnComponent, didn't we have
something like this in MyFaces
Hi!
In my app, there is an
org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter that
binds an entityManager to each request.
With Orchestra do I really have to remove this filter?
No. Orchestra does not help with request scoped beans. Mixing OEMIVF
with Orchestra should work I
Hi!
The complicated thing is, that the pprSubmit enhancement would require a
custom LifeCycle for PPR requests (why is it a PhaseListener by now?)
I am investigating some time into that.
Ok, I've committed something which did the trick. I've not yet fully
replace the PhaseListener
Hi!
Sorry for the lengthy mail ... Solving this problem just made me crazy
so easy problem, and so complicate if not impossible solution with JSF.
Everything I toucht in the last couple of days had some
side-effect/influence on something else.
My simple country/zip immediate show city ppr
Hi!
What do you think about an enhancement for ppr which allows to customize
the DOM update of the response?
So, instead of the simple domElement.innerHtml=xx stuff, one is able
to hook into that and provide his/hers own dom update.
s:pprPanelGroup
Hi!
Now it would be possible to update each component set to JSF 2.0...
but a Tomahawk/JSF2 is expected to be backward compatible. So it
would be difficult to radically change components or eliminate some
duplicates...
+1
I'd like to see this too, though, I think Oracle wouldn't give up
Hi!
are there any plans to release the core15 module ?
soon :-)
I would like open-source the @ConversationName annotation in core15 and
then we should be ready. Volunteering doing the release then?
Ciao,
Mario
Hi!
Just to reiterate: I hate shared! ;-)
Seriously, it seems that Orchestra has to implement a StateManager which
holds the view state in the conversationContext instead of the session.
At the moment it seems that large portions of JspStateManagerImpl can be
reused, but requires to copy it over
Ping!
It seems that Orchestra has to implement a StateManager which
holds the view state in the conversationContext instead of the session.
At the moment it seems that large portions of JspStateManagerImpl can be
reused, but requires to copy it over into Orchestra.
With slight refactoring of
Hi!
Mario, you are not alone in hating the shared concept. ;-)
Good!
1) has a super stable API
That is true, that might be the hardest part.
2) is used (ie. shared) by the myfaces core(!) as well as other myfaces
projects
Sure!
3) may be used by the experienced JSF app
Hi!
Orchestra having its own JspStateManagerImpl sounds interesting
though. Enabling this on Sun Mojarra for example will quite radically
change the way that a JSF app on Mojarra performs. That's not really
Orchestra's role.
I thought about this like an optional feature one has to
... with serialize in state disabled.
I've create a small test case which shows that the attributes map is
just copied over into the state. Which means that each and every
Component shares exactly the same map. Any change to this map will be
reflected in ALL saved states.
Correct would be to
Hi!
It's because the wrong constructor in api's _ComponentAttributesMap
class, it's assigning the map directly:
So we do agree that this needs to be fixed? Then I'll do so ...
Ciao,
Mario
Hi!
sev-en is a new jsf-extension.
Looks Cool, I love it to see that a long standing idea now seems to be
realized.
You posted on the dev list .. cool .. you probably know we are
developers too ... so .. where do we find the code? Or is it just a
too-late April joke ;-)
I think that would make
Hi!
my position on this is we could make sev-en part of orchestra, if the
orchestra crew really, really wants it. If not, this should just be a
separate sub-module in MyFaces. It is interesting enough to stand on
its own.
First, Orchestra is part of the MyFaces community, so it really,
at this amazing editor
http://www.cdolivet.net/editarea/editarea/exemples/exemple_full.html
the best, the code is under apache license!!!
Werner
Check your browser settings FF2 is exactly what I am using to view it :-)
--
mit freundlichen Grüßen
Mario Ivankovits
Hi!
MyfacesBuilderPlugin is almost complete. Actually works for 1.1 and
all interested people could see the example here:
Cool work guys. Great job!
Thanks for all the hard work!
Ciao,
Mario
://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/branches/builder_plugin/bigtest/core_trunk_11/
So please vote if you want to see this feature included on myfaces 1.x
and tomahawk
regards
Leonardo Uribe
--
mit freundlichen Grüßen
Mario Ivankovits
Software Engineering
OPS EDV VertriebsgesmbH
Hi!
I tried deleting the part regardless to persistence from spring
configuration (application-context.xml) but no success. I encountered
exceptions thrown by the Orchestra Conversation Interceptor.
Not configuring the persistence related advice (e.g the
Hi!
Reason #3: The development community is not (so far) very large. Jihoon
Kim's initial code looks nicely written, but it was written as a hobby
project rather than being driven by any long-term goal.
Shouldn't the project go through the incubator for this reason?
MyFaces can be the sponsor
Hi!
Simon and me had to spend 5 hours today to track down a problem which in
the end uncovered a nasty bug in TomahawkFacesContextWrapper. In
.release() the delegation was broken (due to a return in the try block).
Bad stuff :-(
Also I found some questionable stuff:
* Some important todos like
Hi!
[X] +1 for community members who have reviewed the bits
Thanks for being the release-manager again!
Ciao,
Mario
Hi!
why not getElementsByName[0] ?
Well, in general document.getElementById is both faster and more elegant.
So in this case, rendering this component with id=clientId seems reasonable.
Hmm..but it is possible that there are multiple view state fields in
the page, one per form.
Hi!
And also ensure that every ViewState will be replaced and not only the
first [0] one.
When you do have multiple JSF forms (which is valid) each ViewState
needs to be replaced.
Yes, but only when they came from the same view!
I don't know much about JSF portal bridge stuff. Can this
Hi!
I ignore what happens when use multiple jsf portlets in the same page,
or when the page is using multiple forms on the same page (normal
submits should work on both environmets, but ajaxified components?).
With I ignore you mean you will not replace the ViewState for each
form having a
simon schrieb:
In other words, keeping one line of code makes sense (less
maintenance) even if we lose some JSF1.2/JSF2.0-specific features or
performance boosts.
While I second the rest of your mail, I wont do so with the sentence above.
We are developers, and, at least in your younger years
Hi!
Doesn't this change break backward compatibility completley?
The value of the alias= attribute now has to be defined differently,
instead of the el-expressesion just the name needs to be set.
Even if this change is logical to me, a new tomahawk release will break
any existing application
Hi!
Ok, just to say something here too.
If you are going to create an accessibility application you have to put
more work into it than just adding an ALT text to your images.
Since a meaningful default text is not easy to find, if not
impossible, my vote is:
that means:
- log a nag warning
Hi!
One possible enhancement to the error handling feature of myfaces
could be the capability of redirect to a jsf page.
Any concrete use-case for this, or just yet another
cool-we-can-make-it thingy? ;-)
Seriously, what's wrong with the error page capabilities of the webapp
container?
Hi!
What is the current state of MYFACES-434?
I tried to upgrade to the latest Tomahawk+Sandbox and now the
application fails to run properly as the TomahawkFacesContextWrapper
does the AddResource processing AND the ExtensionsFilter does the
AddResource processing. This results in having
Hi Leonardo,
I tried to upgrade to the latest Tomahawk+Sandbox and now the
application fails to run properly as the
TomahawkFacesContextWrapper does the AddResource processing AND
the ExtensionsFilter does the AddResource processing.
The code in extension filter that do
Hi!
the use-case is that people want the same type of functionality they
have in their web.xml (specifying an error-page per exception) in the
JSF-world as well. Just doing it in the web.xml is not sufficient, as
then the faces-context is already closed and not available anymore, so
important
Hi!
Ok then those things are cleared up, now back to the original question
sandbox or own subproject?
+1 for own subproject.
Any further influence with tomahawk/sandbox needs to be avoided.
These two projects are still waiting for a overhaul themself.
Ciao,
Mario
Hi!
(a) create a sub-project myfaces/orchestra/trunk/flow, publish to
snapshot-repo and main myfaces website as normel, but make sure that the
welcome page for the website says SANDBOX in big letters and the version
number is something like 0.0.1
+1
Often even the sandbox will be used also
Hi!
s:xmlTemplate
Dont know much, not to say nothing, about that.
s:pprPanelGroup (is this component ready? it could be good but I don't
know if there is any objection).
I do not think that pprPanelGroup is ready for a release, there are some
things still missing and sometimes it stopps
much more work.
Ciao,
Mario
Thank you.
On Wed, Jul 9, 2008 at 1:39 AM, Mario Ivankovits [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi!
s:xmlTemplate
Dont know much, not to say nothing, about that.
s:pprPanelGroup (is this component ready? it could be good
Hi!
Werner Punz schrieb:
Martin Marinschek schrieb:
In any case, I remain -1 to add a new component library - I am sorry.
Ok I am going to postpone this discussion until I can showcase something
then we can start it over...
Hmm ... was Martin's -1 a veto or did he just express his opinion.
at the new version
before they pick up any of these changes.
+1 from me of course
Regards,
Simon
--
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
Hi!
Note that I will be on holiday until Monday 15 July, so there is no hurry :-)
Monday OR 15 July, both together will not be possible ;-) Well, and even
15 July might be a VERY short vacation. *hehe*
Thanks or the work, I'll look at the artifacts in the next few days,
before my vacation
+0
No chance to look at it for me now, but I trust that you did a good job
again :-)
Ciao,
Mario
On Tue, 2008-07-15 at 23:03 +0200, simon wrote:
Hi All,
The release candidate for MyFaces Orchestra Core 1.2 can be found in the
following places:
Download bundles:
Hi!
If people are happy with adding a note to the tomahawk sandbox page as
described above then I'll do it.
I'd prefer this mark buoy.
Ciao,
Mario
Hi!
This used to work in MyFaces 1.1, but in 1.2 it looks like the fact that
my type is an enum takes precedence over the fact that it implements
EnumCoded interface, so I end up with the built-in EnumConverter instead
of my GenericEnumTypeConverter.
Of course this issue was not relevant in
Hi!
A while ago you added class SpringSingleConversationScope to orchestra
with the comment Mostly useful for dialog/flow frameworks.
The idea was that a dialog can have only one conversation. I can't remember
why we/I thought that we require that. Now that it works without this
limitation I
Hi!
+1 to number one.
Ciao,
Mario
Hi!
Great!
I think it is a good time to make another Orchestra Core release.
There is nothing radical in this new version,
Yep, the radical stuff is kept for the next version ;-)
Ciao,
Mario
Hi!
Example 1)
I've developed some views for a search dialog that I wanted to use in
at
least two different conversations. Everything worked fine for the first
conversation. The following code listing should give you an idea of the
problem.
Simon developed Orchestra Flow which might solve
Hi!
Example 1)
I've developed some views for a search dialog that I wanted to use in at
least two different conversations. Everything worked fine for the first
conversation. The following code listing should give you an idea of the
problem.
However (as noted in my other email) flow
601 - 700 of 974 matches
Mail list logo
