Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #12232 > unrolled thread

Hairy generics question

Back to article view | Back to comp.lang.java.programmer

Contents

  Hairy generics question sclaflin <steve@steveclaflin.com> - 2012-02-21 06:30 -0800
    Re: Hairy generics question Lew <noone@lewscanon.com> - 2012-02-21 09:24 -0800
    Re: Hairy generics question Roedy Green <see_website@mindprod.com.invalid> - 2012-02-21 11:05 -0800
      Re: Hairy generics question Lew <noone@lewscanon.com> - 2012-02-21 12:09 -0800
    Re: Hairy generics question Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-02-21 18:04 -0800
      Re: Hairy generics question Lew <noone@lewscanon.com> - 2012-02-21 18:31 -0800
      Re: Hairy generics question Steven Simpson <ss@domain.invalid> - 2012-02-22 08:31 +0000
    Re: Hairy generics question sclaflin@webucator.com - 2012-02-24 11:12 -0800
      Re: Hairy generics question Lew <noone@lewscanon.com> - 2012-02-24 12:03 -0800
        Re: Hairy generics question sclaflin@webucator.com - 2012-02-24 14:07 -0800
          Re: Hairy generics question Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-02-24 15:36 -0800
            Re: Hairy generics question sclaflin@webucator.com - 2012-02-25 10:27 -0800
            Re: Hairy generics question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-26 13:13 -0400
              What is Model View Presenter. (Was: Hairy generics question) Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-02-26 10:22 -0800
                Re: What is Model View Presenter. (Was: Hairy generics question) Lew <noone@lewscanon.com> - 2012-02-26 13:08 -0800
                  Re: What is Model View Presenter. (Was: Hairy generics question) Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 18:17 -0500
                    Re: What is Model View Presenter. (Was: Hairy generics question) sclaflin@webucator.com - 2012-02-28 06:22 -0800
              Re: Hairy generics question Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-02-28 09:46 -0800
                Re: Hairy generics question Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-02-28 09:49 -0800
                Re: Hairy generics question Lew <noone@lewscanon.com> - 2012-02-28 12:45 -0800
                Re: Hairy generics question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-29 19:37 -0400
                  Re: Hairy generics question Lew <noone@lewscanon.com> - 2012-02-29 22:32 -0800
                    Re: Hairy generics question Arne Vajhøj <arne@vajhoej.dk> - 2012-03-09 21:33 -0500
                      Re: Hairy generics question Lew <noone@lewscanon.com> - 2012-03-10 07:38 -0800
                        Re: Hairy generics question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-10 12:45 -0400
                        Re: Hairy generics question Arne Vajhøj <arne@vajhoej.dk> - 2012-03-10 12:03 -0500
                          Re: Hairy generics question Lew <noone@lewscanon.com> - 2012-03-10 09:47 -0800
                            Re: Hairy generics question Arne Vajhøj <arne@vajhoej.dk> - 2012-03-10 13:26 -0500
                              Re: Hairy generics question Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-11 14:06 -0300
                                Re: Hairy generics question Arne Vajhøj <arne@vajhoej.dk> - 2012-03-11 18:20 -0400
                Re: Hairy generics question Arne Vajhøj <arne@vajhoej.dk> - 2012-03-09 21:43 -0500

Page 2 of 2 — ← Prev page 1 [2]

#12545

On 12-02-28 01:46 PM, Daniel Pitts wrote:
> On 2/26/12 9:13 AM, Arved Sandstrom wrote:
>> On 12-02-24 07:36 PM, Daniel Pitts wrote:
>>> On 2/24/12 2:07 PM, sclaflin@webucator.com wrote:
>>>> On Friday, February 24, 2012 3:03:56 PM UTC-5, Lew wrote:
>>>>> On 02/24/2012 11:12 AM, sclaflin wrote:
>>>>
>>>>> Perhaps the circularity is necessary, but I've worked with my fellows
>>>>> on a few
>>>>> hairy generics issues where circularity seemed necessary, and it
>>>>> never was.
>>>>> Each time it turned out that an acyclic type graph did the trick, and
>>>>> better
>>>>> than the initial circular approach.
>>>>>
>>>>> Of course since you can't share any of the relevant details we have
>>>>> no way of
>>>>> helping you see if there is an acyclic approach. Still, I cannot
>>>>> accept your
>>>>> simple declaration that there isn't. The odds are just too strongly
>>>>> against it.
>>>>
>>>> Lew,
>>>>
>>>> You could well be right.  I based my structure on a framework that had
>>>> Presenter<V>   and View, but then the view didn't know how to talk to
>>>> the presenter.  So, they add in ReverseView<P>   separately.  I was
>>>> trying to combine them both, and with those dual sorts of situations
>>>> I've always ended up with circularity.
>>>>
>>>> You guessed that I've got proprietary code that I can't share, and I'm
>>>> supposed to be spending time on that, not general-purpose things.
>>>> But, if I can come up with a minimal but complete example, I'll post
>>>> it.
>>>
>>> In what way is a Presenter different from a "controller".  View's should
>>> never know about Controllers, only about models.  Controllers know about
>>> specific views and specific models.  Models know about generic
>>> listeners, if you need to have an active view (non web-app stuff).
>>
>> For what it's worth, Daniel, JSF is arguably [1] MVP
>> (Model-View-Presenter) and not MVC (Model-View-Controller). There have
>> been many attempts to characterize JSF as MVC, and that's what most
>> folks think JSF is, but a body has to jump through some hoops in order
>> to define what the V and the C are in JSF in order to make that label
>> stick. MVP on the other hand is a much better description.
> I've just read the original Taligent, Inc. PDF on what MVP is, and it
> looks like its little more than a clarification of MVC, with some new
> concepts pulled out. Things that were inferred in the "controller" are
> now their own concepts.
> 
> In that case, my original advice still stands.  View shouldn't know
> about the Presenter, only about the Model, and event listeners.  The
> Model shouldn't know about the View or Presenter, only about observers,
> and the Presenter is basically knows about everything.
> 
> As such, you can't easily have a Generic Presenter. Also, as such, you
> needn't have the view have any information about the "type" of the
> Presenter. The View also only needs the interface type of the Model, not
> the specific type.  The Model needs only to know only interface types as
> well.
> 
> This allows you to completely remove the circular type dependencies,
> which is one of the main benefits of MVC and MVP architectures in the
> first place.

Let me put it this way. Like I said above, if you're going to make a
distinction between MVC and MVP at all (and a lot of people don't,
because they've never heard of MVP, or they choose not to worry about
the distinction), then MVP describes JSF better than MVC does.

If you choose to think of JSF as MVC - let's say because you aren't
interested in breaking out MVP as a derivative of MVC - then that's fine
too. I have no problem with that, it's what I actually do myself,
because most folks haven't heard of MVP anyway so why confuse them? I
would like it though if people who "knowledgeably" classify JSF as being
MVC could identify what the Controller is in JSF: I've run across more
people than not who either think it's the FacesServlet or just don't know.

AHS
-- 
-- Gaiety is the most outstanding feature of the Soviet Union.
Josef Stalin, November 1935

[toc] | [prev] | [next] | [standalone]

#12550

Arved Sandstrom wrote:
> If you choose to think of JSF as MVC - let's say because you aren't
> interested in breaking out MVP as a derivative of MVC - then that's fine
> too. I have no problem with that, it's what I actually do myself,
> because most folks haven't heard of MVP anyway so why confuse them? I
> would like it though if people who "knowledgeably" classify JSF as being
> MVC could identify what the Controller is in JSF: I've run across more
> people than not who either think it's the FacesServlet or just don't know.

JSF is MVC if you think of a backing bean as a (generally) per-screen 
controller. It coordinates the purely view-oriented actions of the XHTML (JSP 
being out of fashion now) with the POJO logic types that implement the model.

But a JSF application does not have a simple, single-controller MVC structure, 
as people usually think of the architecture. It is similar to Swing, as 
described in
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
(in a section lacking citations):
"An MVC application may be a collection of model/view/controller triads, each 
responsible for a different UI element."

Your distinctions between MVP and MVC are useful, as is your reticence to 
enforce the distinction.

The difficulty isn't that things are or aren't different, it's that the term 
"MVC" is rather broad. It applies to just about any architecture that 
comprises triads of view, model and some coordinating third element. (What the 
hell is the difference between a "controller" and a "presenter", really? I've 
always called it a "dispatcher".) We need a common terminology to distinguish 
the various flavors.

As for people thinking the FacesServlet is the controller, they can be excused 
if they believe the pundits. There are articles about JSF out there that say so.
<http://www.javaworld.com/javaworld/jw-07-2004/jw-0719-jsf.html?page=3>
for example.

So even where the terminology is consistent, the taxonomy is in dispute.

I suppose that at that height, the FacesServlet is the dispatcher and backing 
beans the model, but they're the interaction model, not the business model.

As a programmer I don't face the FacesServlet. (You see what I did there?) 
It's black box and so I dismiss it. The part I design, the part that I model, 
is the application-level MVC pattern. That's why I think of each 
POJO-screen-bean triad as an MVC unit. (MSD in my universe - 
dispatcher-screen-model.) (I did that on purpose. Which leg of the tripod is 
the most important, after all?)

I think we're too late to peg MVC to any one flavor, but it makes sense to 
reserve MVP for the specific variant that it describes. I would go along with 
that.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#12828

On 3/1/2012 1:32 AM, Lew wrote:
> Arved Sandstrom wrote:
>> If you choose to think of JSF as MVC - let's say because you aren't
>> interested in breaking out MVP as a derivative of MVC - then that's fine
>> too. I have no problem with that, it's what I actually do myself,
>> because most folks haven't heard of MVP anyway so why confuse them? I
>> would like it though if people who "knowledgeably" classify JSF as being
>> MVC could identify what the Controller is in JSF: I've run across more
>> people than not who either think it's the FacesServlet or just don't
>> know.
>
> JSF is MVC if you think of a backing bean as a (generally) per-screen
> controller.

It usually have functionality besides controller, so it is not just
a controller.

And clean MVC should have something that is just a controller.

Arne

[toc] | [prev] | [next] | [standalone]

#12838

Arne Vajhøj wrote:
> Lew wrote:
>> Arved Sandstrom wrote:
>>> If you choose to think of JSF as MVC - let's say because you aren't
>>> interested in breaking out MVP as a derivative of MVC - then that's fine
>>> too. I have no problem with that, it's what I actually do myself,
>>> because most folks haven't heard of MVP anyway so why confuse them? I
>>> would like it though if people who "knowledgeably" classify JSF as being
>>> MVC could identify what the Controller is in JSF: I've run across more
>>> people than not who either think it's the FacesServlet or just don't
>>> know.
>>
>> JSF is MVC if you think of a backing bean as a (generally) per-screen
>> controller.
>
> It usually have functionality besides controller, so it is not just
> a controller.
>
> And clean MVC should have something that is just a controller.

QWhat non-controller functionality goes in a backing bean?

I've done a fair amount of JSF work, and the backing beans I've done work just 
like a controller - they coordinate screen events and delegate fulfillment to 
model objects.

I'm not sure where one exactly draws the line between "logic" and "control", 
so perhaps I'm not writing controllers, but your statement is too vague for me 
to discern if that's so. Please clarify.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#12840

On 12-03-10 11:38 AM, Lew wrote:
> Arne Vajhøj wrote:
>> Lew wrote:
>>> Arved Sandstrom wrote:
>>>> If you choose to think of JSF as MVC - let's say because you aren't
>>>> interested in breaking out MVP as a derivative of MVC - then that's
>>>> fine
>>>> too. I have no problem with that, it's what I actually do myself,
>>>> because most folks haven't heard of MVP anyway so why confuse them? I
>>>> would like it though if people who "knowledgeably" classify JSF as
>>>> being
>>>> MVC could identify what the Controller is in JSF: I've run across more
>>>> people than not who either think it's the FacesServlet or just don't
>>>> know.
>>>
>>> JSF is MVC if you think of a backing bean as a (generally) per-screen
>>> controller.
>>
>> It usually have functionality besides controller, so it is not just
>> a controller.
>>
>> And clean MVC should have something that is just a controller.
> 
> QWhat non-controller functionality goes in a backing bean?
> 
> I've done a fair amount of JSF work, and the backing beans I've done
> work just like a controller - they coordinate screen events and delegate
> fulfillment to model objects.
> 
> I'm not sure where one exactly draws the line between "logic" and
> "control", so perhaps I'm not writing controllers, but your statement is
> too vague for me to discern if that's so. Please clarify.
> 
Looking at typical backing beans is a good place to start. A
bog-standard backing bean will have fields, the accessors for those
fields, and action methods.

Everything is up for debate, here, that's the point of this subthread.
:-) I'll sweeten the pot by suggesting that action methods belong to the
Controller, if we are sticking to an MVC picture.

Maybe we'll leave listeners aside for a moment, although some of them
will certainly figure in this discussion.

Now, what about the fields and accessors? As I see it a lot of these are
part of the View, or the presentation state. I think it's seriously
unfortunate that one JSF lifecycle phase is called "UPDATE_MODEL_VALUES"
because to me, as a starting point, the model acted upon here is a
*presentation* model, not the Model in MVC.

This is my initial contribution. I think a typical backing bean is
likely to include bits of both V and C in MVC.

AHS

-- 
Last week I helped my friend stay put. It's a lot easier'n helpin' 'em
move. I just went over to his house and made sure that he did not start
to load shit into a truck.
-- Mitch Hedberg

[toc] | [prev] | [next] | [standalone]

#12842

On 3/10/2012 10:38 AM, Lew wrote:
> Arne Vajhøj wrote:
>> Lew wrote:
>>> Arved Sandstrom wrote:
>>>> If you choose to think of JSF as MVC - let's say because you aren't
>>>> interested in breaking out MVP as a derivative of MVC - then that's
>>>> fine
>>>> too. I have no problem with that, it's what I actually do myself,
>>>> because most folks haven't heard of MVP anyway so why confuse them? I
>>>> would like it though if people who "knowledgeably" classify JSF as
>>>> being
>>>> MVC could identify what the Controller is in JSF: I've run across more
>>>> people than not who either think it's the FacesServlet or just don't
>>>> know.
>>>
>>> JSF is MVC if you think of a backing bean as a (generally) per-screen
>>> controller.
>>
>> It usually have functionality besides controller, so it is not just
>> a controller.
>>
>> And clean MVC should have something that is just a controller.
>
> QWhat non-controller functionality goes in a backing bean?
>
> I've done a fair amount of JSF work, and the backing beans I've done
> work just like a controller - they coordinate screen events and delegate
> fulfillment to model objects.

Typical a backing bean will also contain data.

In Struts you have the form bean / dyna bean with the data
and the action class being the controller.

In JSF the form data and the controller got mixed up a bit.

Arne

[toc] | [prev] | [next] | [standalone]

#12845

Arne Vajhøj wrote:
> Lew wrote:
>> Arne Vajhøj wrote:
>>> Lew wrote:
>>>> Arved Sandstrom wrote:
>>>>> If you choose to think of JSF as MVC - let's say because you aren't
>>>>> interested in breaking out MVP as a derivative of MVC - then that's
>>>>> fine
>>>>> too. I have no problem with that, it's what I actually do myself,
>>>>> because most folks haven't heard of MVP anyway so why confuse them? I
>>>>> would like it though if people who "knowledgeably" classify JSF as
>>>>> being
>>>>> MVC could identify what the Controller is in JSF: I've run across more
>>>>> people than not who either think it's the FacesServlet or just don't
>>>>> know.
>>>>
>>>> JSF is MVC if you think of a backing bean as a (generally) per-screen
>>>> controller.
>>>
>>> It usually have functionality besides controller, so it is not just
>>> a controller.
>>>
>>> And clean MVC should have something that is just a controller.
>>
>> QWhat non-controller functionality goes in a backing bean?
>>
>> I've done a fair amount of JSF work, and the backing beans I've done
>> work just like a controller - they coordinate screen events and delegate
>> fulfillment to model objects.
>
> Typical a backing bean will also contain data.
>
> In Struts you have the form bean / dyna bean with the data
> and the action class being the controller.
>
> In JSF the form data and the controller got mixed up a bit.

You can mix up data and action in Struts, too. Doesn't reflect on the 
framework so much as the practitioner.

Arved's points resonated with me also. Even the Model 2 MVC style has screen 
field awareness in the C; has to, in order to properly dispatch logic. Arved's 
comment pertains, "Everything is up for debate, here, that's the point of this 
subthread."

Whether "JSF is MVC" now sounds like a style issue as I integrate your 
information. I'm in the habit of writing JSF backing beans more like a 
controller and less like a model-aware component, and your experience reveals 
a style with less rigorous a separation. I suggest that while JSF admits of a 
non-MVC approach, as you say, one should yet design along MVC lines.

Just having the MVC pattern in mind, with keen understanding of separation of 
concerns and other principles, one will tend to a good architecture however 
fuzzy the particular label for it. As always, there are no absolute rules, 
only firm, supportive principles.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#12849

On 3/10/2012 12:47 PM, Lew wrote:
> Arne Vajhøj wrote:
>> Lew wrote:
>>> Arne Vajhøj wrote:
>>>> Lew wrote:
>>>>> Arved Sandstrom wrote:
>>>>>> If you choose to think of JSF as MVC - let's say because you aren't
>>>>>> interested in breaking out MVP as a derivative of MVC - then that's
>>>>>> fine
>>>>>> too. I have no problem with that, it's what I actually do myself,
>>>>>> because most folks haven't heard of MVP anyway so why confuse them? I
>>>>>> would like it though if people who "knowledgeably" classify JSF as
>>>>>> being
>>>>>> MVC could identify what the Controller is in JSF: I've run across
>>>>>> more
>>>>>> people than not who either think it's the FacesServlet or just don't
>>>>>> know.
>>>>>
>>>>> JSF is MVC if you think of a backing bean as a (generally) per-screen
>>>>> controller.
>>>>
>>>> It usually have functionality besides controller, so it is not just
>>>> a controller.
>>>>
>>>> And clean MVC should have something that is just a controller.
>>>
>>> QWhat non-controller functionality goes in a backing bean?
>>>
>>> I've done a fair amount of JSF work, and the backing beans I've done
>>> work just like a controller - they coordinate screen events and delegate
>>> fulfillment to model objects.
>>
>> Typical a backing bean will also contain data.
>>
>> In Struts you have the form bean / dyna bean with the data
>> and the action class being the controller.
>>
>> In JSF the form data and the controller got mixed up a bit.
>
> You can mix up data and action in Struts, too. Doesn't reflect on the
> framework so much as the practitioner.

Struts forces you to specify a form bean and an action class, so
unless you pick the same class then they will be separate.

In JSF there is no such separation.

So there is a big difference in the framework.

> Arved's points resonated with me also. Even the Model 2 MVC style has
> screen field awareness in the C; has to, in order to properly dispatch
> logic.

There is a difference between knowing how to process data and
storing the data.

> Whether "JSF is MVC" now sounds like a style issue as I integrate your
> information. I'm in the habit of writing JSF backing beans more like a
> controller and less like a model-aware component, and your experience
> reveals a style with less rigorous a separation. I suggest that while
> JSF admits of a non-MVC approach, as you say, one should yet design
> along MVC lines.

How do you write a managed bean with only control without form fields
properties?

Arne

[toc] | [prev] | [next] | [standalone]

#12863

On 12-03-10 02:26 PM, Arne Vajhøj wrote:
> On 3/10/2012 12:47 PM, Lew wrote:
[ SNIP ]

> 
>> Whether "JSF is MVC" now sounds like a style issue as I integrate your
>> information. I'm in the habit of writing JSF backing beans more like a
>> controller and less like a model-aware component, and your experience
>> reveals a style with less rigorous a separation. I suggest that while
>> JSF admits of a non-MVC approach, as you say, one should yet design
>> along MVC lines.
> 
> How do you write a managed bean with only control without form fields
> properties?
> 
> Arne
> 
You may have lost sight of the forest for the trees, Arne. :-) It's
quite simple, you just write your form EL such that "properties" (input
texts, labels, checkboxes etc) point at one managed bean, and form
actions point at another managed bean.

The ICEDFaces dev team makes these distinctions (see
http://blog.icesoft.org/blojsom/blog/default/2009/04/23/Making-distinctions-between-different-kinds-of-JSF-managed-beans/)

Using their names we see that the one bean I mention above is what they
call a "backing managed bean", and the other is a "controller managed bean".

They also assign - and this jibes with my classification of JSF bits
according to MVC - JSF actionListener and valueChangeListener methods to
the "backing bean" category.

Most people don't split forms JSF code like this - *I* don't - but there
is some merit to thinking about the distinction even if it's only
logical. If one did want to actually code like this, it can be done
cleanly in JSF 2.0 with @ManagedProperty or in CDI with @Inject -
provided that one is cognizant of scopes you can @Inject your backing
bean into the controller bean, and so your action method has clean
access to the backing bean form "properties" via accessors.

AHS

-- 
Last week I helped my friend stay put. It's a lot easier'n helpin' 'em
move. I just went over to his house and made sure that he did not start
to load shit into a truck.
-- Mitch Hedberg

[toc] | [prev] | [next] | [standalone]

#12881

On 3/11/2012 1:06 PM, Arved Sandstrom wrote:
> On 12-03-10 02:26 PM, Arne Vajhøj wrote:
>> On 3/10/2012 12:47 PM, Lew wrote:
> [ SNIP ]
>
>>> Whether "JSF is MVC" now sounds like a style issue as I integrate your
>>> information. I'm in the habit of writing JSF backing beans more like a
>>> controller and less like a model-aware component, and your experience
>>> reveals a style with less rigorous a separation. I suggest that while
>>> JSF admits of a non-MVC approach, as you say, one should yet design
>>> along MVC lines.
>>
>> How do you write a managed bean with only control without form fields
>> properties?
>>
> You may have lost sight of the forest for the trees, Arne. :-)

That happens frequently.

:-)

>                                                                 It's
> quite simple, you just write your form EL such that "properties" (input
> texts, labels, checkboxes etc) point at one managed bean, and form
> actions point at another managed bean.

But then you would need to send over the first managed beans as argument
to the second managed bean.

I don't like that.

 >        If one did want to actually code like this, it can be done
 > cleanly in JSF 2.0 with @ManagedProperty or in CDI with @Inject -
 > provided that one is cognizant of scopes you can @Inject your backing
 > bean into the controller bean, and so your action method has clean
 > access to the backing bean form "properties" via accessors.

Ah.

That would make it useful.

> The ICEDFaces dev team makes these distinctions (see
> http://blog.icesoft.org/blojsom/blog/default/2009/04/23/Making-distinctions-between-different-kinds-of-JSF-managed-beans/)
>
> Using their names we see that the one bean I mention above is what they
> call a "backing managed bean", and the other is a "controller managed bean".

If one want true MVC in JSF that is probably the way to go.

> Most people don't split forms JSF code like this - *I* don't -

Neither does the Java EE tutorial or a common book like Core JSF.

Arne

[toc] | [prev] | [next] | [standalone]

#12829

On 2/28/2012 12:46 PM, Daniel Pitts wrote:
> I've just read the original Taligent, Inc. PDF on what MVP is, and it
> looks like its little more than a clarification of MVC, with some new
> concepts pulled out.

MVC and MVP is certainly closely related.

I would tend to say that MVC is slightly more "input centric"
and MVP is slightly more "output centric".

Arne

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web