headers
Thomas Eyde | 1 Feb 2005 02:54
Picon
Picon

Re: [TFUI] Humble Dialog Versus Microsoft UIB


I can't see that UIP is included in EntLib. The UIP versions 1 and 2 
will give you a lot of headaches and frustrations. Some people on the 
gotdotnet workspace claims success, but none can provide best practices 
or sample code.

UIP is designed to work on both WinForm and WebForm without code change, 
and, IMO, it's here where the design flawed. WebForm and WinForm are two 
different architectures which only appear to be equal.

It could be that UIP works for WinForm applications, but I can testify 
it doesn't on WebForm.

--
Thomas

Timothy Wall wrote:

>Hear, hear.  I looked at a few summaries and got the impression someone  
>has spent entirely too much time locked in a room smelling their own  
>fumes.
>
>This isn't String Theory, so could someone please state what UIP  
>provides in plain and simple terms?
>  
>
>  
>

To unsubscribe, email:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thomas Eyde | 1 Feb 2005 03:08
Picon
Picon

Re: [TFUI] Humble Dialog Versus Microsoft UIB


I will not assume too much, but a fact is that the gotdotnet workspace 
for UIP has been very silent for a while. There are some activity there, 
but I haven't seen any of UIP's creators been in there. All of the 
critical questions remains unanswered. It's easy to think that they have 
bailed out, instead of just admit their failure.

I don't know if they grok MVC or Humble Dialog, but they certainly don't 
grok ASP.NET. If they do, they don't respect the architecture. We can 
have our opinions on how good or bad that architecture is, but going 
against an architecture was never a good idea. And that's what UIP does.

--
Thomas

Marc Brooks wrote:

>>that slight difference in who calls who when is everything.  What
>>makes Humble Dialog less complicated, and more testable, is the fact
>>that the view does not need to know what the controller needs, it just
>>needs to tell it to do something.
>>    
>>
>
>That's 100% my read also.  The new Enterprise Libary doesn't include a
>revamped UIB, probably because they're still struggling to learn this
>very difference.
>
>  
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phlip | 1 Feb 2005 05:19
Picon
Gravatar

[TFUI] Re: [TDD] Re: A better way to test the GUI?


Charlie Poole wrote:

> > Is my estimate correct that there is no widespread, commonly
> > available canvas control available for the Java GUIs and C# GUIs?
> >
> > This is not rocket surgery. If you don't need super-advanced
> > real-time visualizations, then you don't need raw paint
> > commands. The effort to mock those commands exceeds the
> > effort to build a simple canvas control, like Tk Canvas.
>
> I'm not entirely sure what you mean by a canvas control. I was
> responding
> to the notion that it's relatively simple to mock the Graphics object.
> Maybe
> that's not what you meant though...

Divide all of TFUI into two kinds: Reusing controls that animate data (such
as edit fields and combo boxes), and building new controls that animate data
(such as heat maps, contour maps, etc.).

To build a new control, you can use a canvas control, or you can use raw
paint commands. The latter is typically "non-retained", so you must work
extra to retain those graphic commands, so tests can query they were on
track.

When a canvas control treats graphic commands as objects, it can, for
example, create a rectangle, and then seamlessly move that rectangle around,
change its attributes, etc. The canvas handles the low-level details,
including retaining commands. The rectangle is an object, with properties to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Howells | 1 Feb 2005 10:15
Picon
Favicon

RE: [TFUI] Humble Dialog Versus Microsoft UIB


>>It could be that UIP works for WinForm applications, but I can testify 
>>it doesn't on WebForm.

And from your other message

>>I don't know if they grok MVC or Humble Dialog, but they certainly don't
>>grok ASP.NET. If they do, they don't respect the architecture. We can have
>>our opinions on how good or bad that architecture is, but going against an
>>architecture was never a good idea. And that's what UIP does.

Hi Thomas,

Can you be a bit more specific on how/why it doesn't work and how it goes
against the architecture?

I am interested because I am getting close to the end of an ASP.NET project
using UIB almost exclusively.  Now my case is a bit special - I am a team of
one developer, it's my first ASP.NET project, I don't come from a trad ASP
background, I'm not doing Test First.

I made it work for me.  Yeah - there are things I don’t like, I did find
some headaches, and I think the documentation is both huge *and* largely
useless.  But it has provided a *lot* of infrastructure that I didn't have.

My project is not huge - a single .net solution - 50 (ish) aspx files, 3
other assemblies and a couple of other projects for converting/loading
legacy data. SQL Server database 25 tables.

I'm really interested in your experience.  I can take it if I have made the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phlip | 1 Feb 2005 15:51
Picon
Gravatar

Re: [TFUI] Humble Dialog Versus Microsoft UIB


Richard Howells wrote:

> I am interested because I am getting close to the end of an ASP.NET project
> using UIB almost exclusively.

Could you do us a major favor and do what MS couldn't - briefly sumarize UIB?

--

-- 
Phlip

To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe@...

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/TestFirstUserInterfaces/

<*> To unsubscribe from this group, send an email to:
    TestFirstUserInterfaces-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply | 13 comments |
headers
Phlip | 1 Feb 2005 16:01
Picon
Gravatar

Re: Re: A better way to test the GUI?


Charlie Poole wrote:
> 
> Hi Phlip,
> 
> > Divide all of TFUI into two kinds: Reusing controls that
> > animate data (such as edit fields and combo boxes), and
> > building new controls that animate data (such as heat maps,
> > contour maps, etc.).
> 
> As well as much more mundane controls... at least in markets
> where the appearance of ui elements is considered important.

That's the thing: When mundane controls provide an "ownerdraw" system,
they provide back-doors to override part of their paint events.
(That's how your Windows XP window title bars can look like fish
tanks, folks...)

But painting efficiently requires non-retained graphics, so you are
back to either letting testing slide, or using Mock Graphics.

If you just need a stoopid gradient inside a pushbutton, forget test-first.

> > To build a new control, you can use a canvas control, or you
> > can use raw paint commands. The latter is typically
> > "non-retained", so you must work extra to retain those
> > graphic commands, so tests can query they were on track.
> >
> > When a canvas control treats graphic commands as objects, it
> > can, for example, create a rectangle, and then seamlessly
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Eyde | 1 Feb 2005 20:57
Picon
Picon

Re: [TFUI] Humble Dialog Versus Microsoft UIB


It's been a while since I worked with UIP, but here are something which 
I remember:

UIP depends on the Session State, but fails to detect when the session 
state is gone. When this happens, everything you try to do will fail 
with an exception.

ASP.NET is not servlets. You can implement your own HttpModules which 
can receive all calls and then delegate to some aspx, but you have to be 
carefull if you want to keep view state and postback events. ASP.NET 
creates the view first and pass the control to that view. UIP tries to 
reverse that order without modules and that's one thing which causes the 
Session State glitch.

You have to manually connect a controller to its view in Web.Config. Not 
excactly counter-architecture, but you end up with a huge web.config. 
It's easy to forget to rename the class/view names in web.config when 
you rename them in code. I never understood why this is necessary, all 
views has to know their controller anyway, as they have to cast from the 
generic Controller.

The concept of navigation graphs is broken. It doesn't work. I never 
managed to pass data between nav graphs.

But then again, it could be that I was using UIP the wrong way. 
Unfortunately for me, I got no corrections.

--
Thomas
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phlip | 6 Feb 2005 05:10
Picon
Gravatar

[TFUI] The TFUI Principles


Gang:

I have returned to my perennial essay (after a sabatical applying
Broadband Feedback to a crunch-mode situation...).

	The TFUI Principles
GUIs and GUI testing provide a roadbump to those learning Test Driven
Development. Given a difficult combination of experience, tools, and
goals, folks meet with common problems and mistakes. This essay
addresses the problems and issues GUIs generate, and constructs a
strategy that ports to any GUI situation.

	What is Test Driven Development?
Briefly, write failing tests, write code to pass them, and then
refactor the code to improve its design. After the fewest possible
edits - say ten at the most - run all the tests, and predict their
results. This technique makes the odds of bugs and the odds of excess
refactoring very low.

	Why Test FIRST?
Why wash your hands before performing surgery? TDD is a good habit
that trades long hours debugging for short minutes writing new test
cases. Prevention is better than a cure. If tests unexpectedly fail,
passing tests should only be an Undo away.

	Why is TDD for GUIs naturally hard?
The target situation this: We should be able to write new test cases
that force /predictable/ changes in a GUI's appearance and response.
All other libraries submit to program control, making prediction easy.
(Continue reading)

Permalink | Reply | 19 comments |
headers
yahoogroups | 6 Feb 2005 12:52

Re: [TFUI] The TFUI Principles


Hi Phlip,
Glad to see you're back!

A couple of weeks ago I came up with an
interesting insight. If you drive the UI with
FIT, and relentlessly remove all duplication
from both the FIT tests and the GUI, then
you ought to get the separation of
function that everyone has been advocating
for years.

Comments?

John Roth

----- Original Message ----- 
From: "Phlip" <phlip2005.at.gmail.com@...>
To: "testfirstuserinterfaces@..." 
<testfirstuserinterfaces.at.yahoogroups.com@...>
Sent: Saturday, February 05, 2005 10:10 PM
Subject: [TFUI] The TFUI Principles

>
> Gang:
>
> I have returned to my perennial essay (after a sabatical applying
> Broadband Feedback to a crunch-mode situation...).
>
> The TFUI Principles
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ron Jeffries | 6 Feb 2005 14:49
Favicon

Re: [TFUI] The TFUI Principles


On Sunday, February 6, 2005, at 6:52:58 AM, yahoogroups@... wrote:

> A couple of weeks ago I came up with an
> interesting insight. If you drive the UI with
> FIT, and relentlessly remove all duplication
> from both the FIT tests and the GUI, then
> you ought to get the separation of
> function that everyone has been advocating
> for years.

> Comments?

Interesting idea ... I'd love to see a series of articles
demonstrating this.

Ron Jeffries
www.XProgramming.com
You can observe a lot by watching. --Yogi Berra

To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe@...

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/TestFirstUserInterfaces/

<*> To unsubscribe from this group, send an email to:
    TestFirstUserInterfaces-unsubscribe@...
(Continue reading)

Permalink | Reply | 0 comments |

Gmane