Re: [Openaaq-discuss] Re: New code from Michael

[Michael M. <mi...@wi...>]

Alex Polkovsky wrote:

>Thanks, Michael. I'll check it out and, I think, post it to the
>Sourceforge site as add-on code.
>
>The shared.pl code is problematic mainly because it should be a cleanly
>coded module. Right now nothing has a defined variable scope. I still
>think the model has allot of possibilities because at some point there
>could be a module to control client, question and administration
>fields.
>
>I'm almost 100 pages into Damian Conway's Object Oriented Perl. It's a
>good book, and making a module looks very functional for shared.pl.
>
>The idea of using server side includes actually comes as a clean way to
>combine AAQ with existing user login systems. Sites that have a user
>profile system usually design it for other needs, like e-commerce, and
>don't think about AAQ.
>  
>
An object-oriented AAQ would definately been interesting.  I am of the
opinion that the definition of interfaces is most important.  Once
interfaces between different parts of a system are defined then an OO
model comes somewhat easier.  Interestingly, one of the developers of
the Java language was answering questions a few years ago and was asked
what he would change in Java if he could start over again.  He replied,
"I would leave out objects" and everybody laughed.  He was partly
serious though.  He believes that langauges should promote so-called
"interface inheritance" over object inheritance.  In Java that means you
would define object that "implement" an defined interface rather than
inherit an actually parent object.  In practical terms this means that
you come up with a number of function calls and fix the names... any
object with those function is said to implement the interface.  You can
avoid the problems of multiple-object-inheritance by making objects that
have no parent but implement many interfaces.

This would work well for AAQ if it was turned into an N-tier
architecture.  Basically make some of it into web-services with no
visual presentation.  Then write other applications that interface with
web-services but that are responsible for presentation.  You could have
more than two-layers in some cases.

I'll stop ranting and raving now.


>Again, thanks.
>
>Alex
>
>
>
>
>
>
>
>
>
>ope...@li... wrote:
>  
>
>>Alex Polkovsky wrote:
>>
>>    
>>
>>>Michael, I have a bunch of questions for you.
>>> 
>>>
>>>      
>>>
>>Hi Alex,
>>
>>Attached is a tar archive containing the new programs I wrote for
>>posting AAQ questions.  Below are my answers to your previous questions. 
>>
>>Here are some notes about my new code:
>>
>>There are three programs:  post_public, post_postsecondary, and
>>choose_institution:
>>  post_public posts questions for public libraries
>>  post_postsecondary posts questions for post secondary libraries but
>>requires that a parameter be passed specifying which institution (as the
>>values of the form depend on the institution).
>>  choose_institution generates a form for picking an institution and
>>submits to post_postsecondary (not used for post_public at all).
>>
>>There are a number of html and text files that are all templates used by
>>the programs.  All pages that the programs display come from a
>>template.  So the appearance can be changed completely just by editing a
>>few templates. 
>>
>>I use Text::FastTemplate for templating.  I believe it is the
>>appropriate templating system for these quick and dirty scripts.   The
>>template toolkit might be more appropriate for a better designed and
>>larger system.
>>
>>The new programs do a fair bit of error checking.  Almost anything  (but
>>not everything) that could go wrong will be caught.  I don't really do
>>anything special if an error condition occurs yet.  I plan to add some
>>logging abilities later.
>>
>>I don't do any checks on input which is very bad.  The old OpenAAQ is
>>vulnerable to cross-site scripting attacks and this code is too.
>>
>>To use the programs you will need to at least edit the database username
>>and password constants.
>>
>>My new programs create a new customer account for every question.  At
>>first that might look like an error or a bug, but it is the desired
>>behavior.  We were facing a problem of customers who had multiple
>>affiliations, or who had changed affiliation, or who had changed email
>>addresses.  Since there is no account managment option for the customers
>>we decided that a quick and dirty hack would work.  The customer has no
>>"account" as far as they are concerned and they must provide their
>>affiliation and contact info with every question.  We still create new
>>customer accounts... one per question.  At some later date I will write
>>a program to reap old accounts.  I don't think this is the correct
>>solution... but it was as good as I could get for next to zero effort. ;-)
>>
>>I am working on another change to AAQ right now as well.  I was asked to
>>allow for two-way-conversation between customer and librarian.  Again, I
>>need to apply as little effort as possible.  So I am going to use
>>"variable envelope return paths" to assign a unique email address to
>>every question.  A customer can reply to the notification email they
>>get, and their replies will be appended to the original question (in the
>>database it will be added as addition text in some way).   I have not
>>completed this portion yet, but I will share it when it is ready.  It
>>will depend on having a mail server such as qmail or postfix where you
>>can have email address like "aaq...@yo..." where
>>"anything" could be some ID number and all email to addresses starting
>>with "aaq-" will be sent to a program that parses them.  The program
>>parses out the ID after the "aaq-" part to identify what question the
>>email should be appended too.
>>
>>    
>>
>>>What version of MySQL are you running?
>>> 
>>>
>>>      
>>>
>>The latest in the 4.0.X series.  I will be upgrading to 4.1 very soon.
>>
>>    
>>
>>>Are you using a standard perl module for te HTML templates?
>>> 
>>>
>>>      
>>>
>>Text::FastTemplate
>>
>>It is about as light weight as you can get.  It outperforms
>>HTML::Template and has a simple syntax.  Not powerful like the template
>>toolkit though.  For a short CGI that is not part of a much larger
>>infrastructure, Text::FastTemplate is my favorite.
>>
>>    
>>
>>>You wrote two scripts, but OAAQ has the database driven functions for
>>>creating modified pages for just such an implementation. Did the
>>>shared.pl code (gross as it is) get in your way?
>>> 
>>>
>>>      
>>>
>>Sadly, I did have problems getting the existing code to work.  I
>>inititally made modifications to the existing post.pl program.  But
>>things were not displaying the way I expect.  I am familiar with the
>>code and felt I had covered my bases, but after about 4 hours of
>>debugging I decided to take a more daring path and wrote a new post
>>script and ended up liking it.
>>
>>    
>>
>>>I like your Net::SMTP implementation. That would take one more
>>>uncertainty out of installation. I may grab that idea.
>>> 
>>>
>>>      
>>>
>>It is more or less easy to use and you can get some debugging info in
>>the event that mail cannot be delivered.
>>
>>    
>>
>>>I'm pushing myself to redo post.pl under the followig design:
>>>
>>>1. same one page model; any preceeding pages can be used to profile a
>>>user by imagemap, preceeding form or a user login mechanism belonging
>>>to the site.
>>>
>>> 
>>>
>>>      
>>>
>>I was also thinking that an AJAX (danger... buzzword) client might be
>>interesting.  Right now I use two programs for the postsecondary part,
>>but with AJAX that could be one "form" with several web services behind it.
>>
>>    
>>
>>>2. Complete HTML page or Apache server side include. a server side
>>>include is called in the page with
>>><!--#exec cmd="/location/post.pl '$QUERY_STRING'" -->
>>>and this permits OAAQ to function in complicated HTML sites. Also, you
>>>will one day be able to use c/post.pl to add a post form to the same
>>>page that c/search.pl adds a search form to.
>>> 
>>>
>>>      
>>>
>>That is a really neat idea.  You could convert my program do that by
>>simply changing the templates I think.
>>
>>    
>>
>>>4. Email verification will split email on the @ and attempt to resolve
>>>the IP address of the mail server. I'm guessing Net::SMTP could request
>>>verification of an account from a mail server, but I think too many
>>>servers will not reply out of some setting meant to filter spam.
>>> 
>>>
>>>      
>>>
>>I did put in a small bit of code to check the sanity of the email
>>address.  If the email address looks wrong it tells the user but allows
>>them to use the "bad" email address if they check a checkbox.  This
>>helps in situations where someone might have a valid email address but
>>that is weird enough that we might think it is wrong. (emails with
>>punctuation for example).
>>
>>    
>>
>>>5. support for sites reuiring no email in favor of phone. Later, I will
>>>look at staff modules to allow phone as the responce method and a "do
>>>not send responce" swich.
>>> 
>>>
>>>      
>>>
>>That's a good idea.
>>
>>    
>>
>>>6. create a new client record for every post. that may seem like bad
>>>database design, completely ignoring normalization, but without a
>>>verifiably unique key I'm stuck.
>>> 
>>>
>>>      
>>>
>>Haha... that is exactly what I did.  Great idea!  In the long run it
>>would be nice to be able to install OpenAAQ and as an admin choose
>>weather there should be accounts or no accounts.  If there are accounts
>>it would be nice to have an account managment applications that users
>>could access to update their contact info, select affiliations etc.  Of
>>course if they could do that it just begs more questions about how the
>>system would work.
>>
>>
>>    
>>
>>>Alex
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>ope...@li... wrote:
>>> 
>>>
>>>      
>>>
>>>>Hello Everyone,
>>>>
>>>>I also have something to contribute. Recently I re-wrote the AAQ client
>>>>(post.pl essentially). I wrote two new version (one for the public
>>>>library users at my consortium and one for the post-secondary users). I
>>>>made some significant changes.
>>>>
>>>>1) The HTML the program displays and the email it sends out are based on
>>>>templates
>>>>2) I use Net::SMTP to send email
>>>>3) There is more error checking in the database code
>>>>4) I use transactions in the database code (so if one pieces fails the
>>>>whole thing stops and rollsback what it was doing).
>>>>5) User registration is not required (the system stores all the user
>>>>info but does not track the user's identity with a cookie)
>>>>6) One screen is used to collect all information from the user
>>>>
>>>>I will make the new code available as soon as possible.
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>-------------------------------------------------------
>>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>>      
>>>
>>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>    
>>
>>>informative Webcasts and more! Get everything you need to get up to
>>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>>_______________________________________________
>>>Openaaq-discuss mailing list
>>>Ope...@li...
>>>https://lists.sourceforge.net/lists/listinfo/openaaq-discuss
>>>
>>> 
>>>
>>>      
>>>
>>    
>>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>_______________________________________________
>Openaaq-discuss mailing list
>Ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openaaq-discuss
>
>  
>