perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luiz Fernando B. Ribeiro" <l...@engenhosolucoes.com.br>
Subject Re[2]: Design decision / embperl or mason? :-)
Date Tue, 23 Mar 2004 22:44:00 GMT
Oliver,

Tuesday, March 23, 2004, 6:50:05 PM, você escreveu:

OB> to give you a glue what I'm talking about I'll try to tell
OB> you something aboutthe features of the application:
OB> - user login (session management)
OB> - editing and of course creating a user profile
OB> - personalized user profile (differend colors, fonts - ok, CSS is my friend
OB>     but also should be stored in a database)
OB> - creating a user specific page with personalized information
OB>     (calendar/reminder function, picture, birthdate etc)
OB> - sending and recieve short messages (called SMS for GSM phones)
OB>     to/from other users if they have an account in my portal)
OB> - sending little messages to other users (inbox/outbox - own
OB>     messaging system, not based on pop/smtp!!!)
OB> - creating own little "information channels" I mean messages that
OB>     should be posted at the personlized site of other users if they
OB>     supscript to these "information channels" from other users
OB> - uploading pictures
OB> - wide database searches, searching for other users and content
OB>     (DBIx::Recordset :-)

I think you will have no problems with this.

OB> One of the most important things for me is the MVC - pardigm because
OB> I want to separate content and logic. How can I implement this method
OB> with embperl? (Because embperl is embedding perlcode in HTML) It's more
OB> the JavaServerPages/Java Beans concept I prefer. Only snippets of 
OB> perlcode in
OB> my HTML and behind that the more logical stuff if needed.

To achieve this I implement the logic of the application in a module
using OO syntax. In the pages itself I try to maintain
just the basics to layout the page.

To avoid restart the server, as Ed noted, you can also use
Apache::Reload, or implement your own change detect mechanism.

Currently, I use the following design:

Database level: My own but could be DBIx::Recordset
Application level: Perl modules implementing the logic
Interface level: a bunch of Embperl "objects" implementing an API to
build forms, session management, screen handling, and anything
reusable related to output; and another bunch of Javascript libraries
to help with HTML tricks, CSS, and etc.

The Embperl "objects" are a better place to implement parts of the logic
related to output because you can use the power of Embperl instead of
print OUT and other tricks when you have to output inside common perl
modules. This also gives you a very good way to reuse code, I use my
"objects" in all my current projects, just like any plain perl module.

With this implementation I think things are well isolated, and as Ed
noted also, the logic is available to command line tools.

Maybe other people have other suggestions on this matter.

OB> I know this too but thanx for your information and feedback.
OB> I appreciate :-) Any additional questions about the application, luiz?

I think you will have a lot of fun in the near future...

Regards,

-- 
Luiz Fernando B. Ribeiro
Engenho Soluções para a Internet


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Mime
View raw message