Seems fine to me. If you were going to go
truly OO (and potentially overboard depending on how many search types you
might have) on the back end you might implement your filter classes to know how
to actually do the search themselves. That way instead of having a switch
statement based on the filter type you would actually just tell the filter to
do the search. This is minor and doesn’t affect you on the Flex side.
Matt
From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Scott
Barnes
Sent: Tuesday, July 12, 2005 11:40
PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Searching
with FLEX, whilst implementing re-use.
I've been reluctant to post about this concept, mainly as I feel I am
missing some much needed OOP skills. None the
less, here goes nothing.
Situation:
I have a MXML component (basically a container,
with TextField, Search
Button ..or more...) that I want to re-use
consistently throughout an
application via a standard dialog. Yet, at the
same time the Context
of this search criteria may differ depending on
what the user is
currently doing (ie Search for Users or they could
be in invoice
management, and want to search for an invoice).
Part of this design, is that rather then building
individual
forms/logic associated to each Context (that or
simply extend it for
the off chance it changes), I decided to marry the
concept of a
FilterClass with the SearchForm.
I've proposed that with each implementation of a
form, you nest a
FilterClass node within your MXML, the purpose of
this node is define
how to execute a intended search for thine
context.
The point is, I want to send a serialized object
to my RemoteObject,
which then unpacks that data, works out what
execution plan it needs
to undertake and carries it out accordingly.
So lets assume I have the following approach to my
search:
1) User enters keyword into TextField
2) User clicks Search (doSearch())
3) doSearch extracts Keyword from known textfield,
instantiates
associated (context specific) filterClass and sets
keyword accordingly
4) doSearch invokes validate() on associated
filterClass, checks for
exceptions if none, continues.
5) doSearch sends filterClass to
RemoteObject.method
(com.mossyblog.flexGateway.search(filterClass))
aka "flexGateway"
6) flexGateway unpacks (filterStruct) the
serialized filterClass,
deterimes its type (case statement) and invokes
known methods relating
to such type (ie searchInvoices(filterStruct))
7) searchInvoices invokes whatever needed methods
it has, in order to
carry out a search (ie pass information to a
manager within the model,
which in turn passes deserialized arguments to
associated datalayer)
8) searchInvoices returns a known data type back
to the flexGateway
9) flexGateway either then returns that data type
to doSearch or
re-packs into a more Flex friendly format and then
hands it back
10) doSearch uses that information to populate a
datagrid etc.
How does this concept float? hold water? or can
anyone improve on
thine strategy?
--
Regards,
Scott Barnes
http://www.mossyblog.com
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
YAHOO! GROUPS LINKS
