Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. calling polymorphic function in Selenium question (MH)
2. recursively retrieving widgets handlers in wxhaskell (legajid)
3. Re: recursively retrieving widgets handlers in wxhaskell
(Felipe Lessa)
4. Re: recursively retrieving widgets handlers in wxhaskell
(Stephen Tetley)
5. Re: recursively retrieving widgets handlers in wxhaskell
(legajid)
----------------------------------------------------------------------
Message: 1
Date: Sun, 4 Apr 2010 21:25:16 -0400
From: MH <[email protected]>
Subject: [Haskell-beginners] calling polymorphic function in Selenium
question
To: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
I am running the following code that is using Selenium. If you look at
the function "start", you will see that the return type of the
function is polymorphic. Now in main function, I call start function
to get selenium IO monad and sequentially call selenium commands
(open, doCommand etc...). The problem that I have here is, while I can
call all Selenium commands with signature (String -> Selenium
String), I can't call commands with signature (String -> Selenium
Bool). As I understand it, even though "start" function shall return
IO (Selenium a -> IO (Either String a)), it actually return IO
(Selenium String -> IO (Either String String)).
How shall go about fixing this problem?
I need to be able to call both types of Selenium commands
1. doCommand :: SCommand -> [String] -> Selenium String
OR
selectFrame :: String -> Selenium String
AND
2. isTextPresent :: String -> Selenium Bool
Thanks.
=========================================================
module SeleniumTest where
import Control.Monad.Error
import Data.Maybe
import Network.BSD
import Network.URI
import Test.Selenium.Server
import Test.Selenium.Syntax
infixr 0 $$
-- | Starts up a session and returns a wrapper function that will run
-- commands. Gives common defaults for browser and host.
start :: String -> IO (Selenium a -> IO (Either String a))
start url = do
-- host <- getHostName
start' Firefox "localhost" url
-- | Starts up a session and returns a wrapper function that will run
-- commands.
start' :: Browser -> HostName -> String
-> IO (Selenium a -> IO (Either String a))
start' browser host url = do
let uri = fromJust (parseURI url)
sel = mkSeleniumRCSession host browser uri
result <- runSelenium sel startSelenium
return $ runSelenium (either (\msg -> error msg) id result)
($$) :: Show t => (Selenium () -> r)
-> Selenium t -> r
($$) s c = s $ do r <- c; liftIO (putStrLn $ "Result: " ++ show r); return ()
-- | Stops a session (in the wrapper returned by start)
stop :: Selenium ()
stop = stopSelenium
--main::IO()
main = do
selenium <- start "http://www.google.com";
selenium $ open "/"
selenium $ doCommand SWindowMaximize []
selenium $ typeText (Name "q") "stuff"
selenium $ clickAndWait (Name "btnG")
return selenium
===============================================================
------------------------------
Message: 2
Date: Mon, 05 Apr 2010 14:17:40 +0200
From: legajid <[email protected]>
Subject: [Haskell-beginners] recursively retrieving widgets handlers
in wxhaskell
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
trying wxHaskell GUI interface, i would like to get a list of all
widgets in a frame.
My frame is composed of 4 widgets and a panel containing 2 widgets.
wlf <- get frame children gives a list of 5 widgets (4 + 1 panel)
wlp <- get panel children gives a list of 2 widgets
Making wlf ++ wlp gives the whole list of widgets in the frame.
But, for a more general use, i want to explore recursively the
hierarchy from frame, without having to explicitly know wether the
frame contains other containers ...
Since the <- syntax to get a list of children, i can't figure out how
to write the recursive function to get all children of a frame.
I can't write (x <- get widget children) ++ f (rest of list of
widgets) , as for usual functions using lists.
Thanks for helping.
Didier.
------------------------------
Message: 3
Date: Mon, 5 Apr 2010 09:51:38 -0300
From: Felipe Lessa <[email protected]>
Subject: Re: [Haskell-beginners] recursively retrieving widgets
handlers in wxhaskell
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Mon, Apr 05, 2010 at 02:17:40PM +0200, legajid wrote:
> trying wxHaskell GUI interface, i would like to get a list of all
> widgets in a frame.
I can't answer your question as I don't use wxHaskell. That
being said, I don't see a reason why you would want to do that.
What are you trying to do? Perhaps we could propose you a better
solution.
Cheers,
--
Felipe.
------------------------------
Message: 4
Date: Mon, 5 Apr 2010 14:11:00 +0100
From: Stephen Tetley <[email protected]>
Subject: Re: [Haskell-beginners] recursively retrieving widgets
handlers in wxhaskell
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hi Didier
I think I've simplified what you are saying to remove the dependency
on wxHaskell. Recursing a widget hierarchy to all get a list of all
widgets seems a bit strange, though demo1 does this.
Generally I'd expect you would want to recursively process the widget
hierarchy collecting some attribute of each widget - demo2 does this.
I've put the recursive functions into the IO monad to model wxHaskell
where widgets are in some monad.
code follows...
-- Model widgets as a simple binary tree - labels and interior
-- nodes both have names.
--
data Tree = Leaf String
| Node Tree String Tree
deriving (Show)
-- simulate the 'get children' on a widget -
-- the function is in the IO monad as an analogy
-- to wxHaskell being in some monad.
--
children :: Tree -> IO [Tree]
children (Leaf _) = return []
children (Node l _ r) = return [l,r]
-- allTrees returns a list of trees -
-- the current tree (t) plus trees of all children (kids_deep)
-- Again in the IO monad to simulate wxHaskell being in some
-- monad.
--
allTrees :: Tree -> IO [Tree]
allTrees t = do
kids <- children t -- [Tree]
kids_deep <- mapM allTrees kids -- [[Tree]]
return (t : concat kids_deep)
tree1 = Node (Leaf "a") "top" (Node (Leaf "c") "node_b" (Leaf "d"))
demo1 = allTrees tree1
-- Simpler idiom just collecting an 'attribute' at each level
-- of the tree - here the name.
--
allNames :: Tree -> IO [String]
allNames t = case t of
Leaf s -> return [s]
Node l s r -> do { ls <- allNames l
; rs <- allNames r
; return (s:ls ++ rs)
}
demo2 = allNames tree1
------------------------------
Message: 5
Date: Mon, 05 Apr 2010 18:07:27 +0200
From: legajid <[email protected]>
Subject: Re: [Haskell-beginners] recursively retrieving widgets
handlers in wxhaskell
To: Stephen Tetley <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Stephen,
Thanks for your answer. I'll look at it carefully to insert it into my
project.
My question came from my project : manage a book library.
A main frame lists all the books in a listCtrl.
On this frame, an menu option allows selections on different criterias
(author, title, ...).
After validating selection, the listCtrl is loaded again, with the books
answering the selections.
The structure of my program is this one :
frame -> intial loading of data (no selections)
frame -> menu option -> selection frame then when validated
loading data (selections here
are updated in the sql query)
The loading function is called from two different functions.
I want the loading function to display the number of books selected in
the status bar.
To do this, the function "loading" must get the status field handler. So
the selection menu option too, to be able to give it to the "loading".
It's a bit boring since "selection" doesnt't need it at all, except to
pass it to another function.
Adding new functions will certainly add new parameters for their
specific needs.
My strange idea was : as i have to pass the main frame handler to my
functions, the loading function could explore the hierarchy to find the
status field, since i give it a specific value for "identity" attribute.
So, the only parameter, common to all functions, will be the main frame
handler.
Why do i pass the main frame handler ? Because my selection function
displays a modal dialog, that must refer to the "calling" frame.
I see a problem with this approach : no more reference to a field at
compilation time (just a handler with a value like 0x.......), so
possible error at run time.
A second issue is : status field in a statusbar has no identity
attribute, like other widgets have (text, buttons, ...). In this
specific case, my idea has no solution; i have to change the statusbar
into a simple label.
But, i want to keep the idea when i write an export function, so the
main frame displays a rolling counter as long as the books are written
in a csv file.
Has anyone already experimented this kind of project? Am i right to do
this? Is there another way ?
Thanks,
Didier
2. n
Stephen Tetley a écrit :
> Hi Didier
>
> I think I've simplified what you are saying to remove the dependency
> on wxHaskell. Recursing a widget hierarchy to all get a list of all
> widgets seems a bit strange, though demo1 does this.
>
> Generally I'd expect you would want to recursively process the widget
> hierarchy collecting some attribute of each widget - demo2 does this.
>
> I've put the recursive functions into the IO monad to model wxHaskell
> where widgets are in some monad.
>
> code follows...
>
>
> -- Model widgets as a simple binary tree - labels and interior
> -- nodes both have names.
>
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 22, Issue 6
****************************************
