I've been pondering, my recent post has had me wondering if the method I am using is the best?

Hmm, seeing you don't mention what you ARE using or show code I am wondering too....

I need some help organizing what would be best in this situation.

And this situation would be the one that you fail to describe in any relevant detail I suppose. Perhaps that is unfair. You do mention data storage and output formatting which does limit it to say 50% of all the computer code ever written.

1. Explore CPAN
2. Define what it is you want to do and why.
3. See 1 - whatever you are trying to do it will almost certainly have been done before
4. See 2 based on what you find at 1 as CPAN code has generally been written by people who have thought about it for a long time.
5. Learn how to ask a question, I have no idea what you are talking about based on what you have written. Nor I venture to say does anyone else.

Speculating on your title, perhaps you are looking for HTML::Template Tutorial as this is an excellent way to deal with databases and HTML output.

I have to echo brother tachyon -- your question is vague (but you said you were tired).

Here's what I suggest. Sit down with a full cup of coffee (or whatever) and a blank sheet of paper and draw

• How you want to use the thing you're hacking together, and
• How you think the database objects might be structured.

Don't start with the tools and try to solve the problem. Start with the solution and look for a build it with the tools you have available to you.

And if you have a specific Class::DBI question, ask it in another node -- don't come back and update your original post. No doubt there are nodes scattered around The Monastery that discuss that module. Learn as much as you can from them.

You seem to be using a 2 layer system. But until you flush out the details, I won't say much more on what exactly you are doing. I'm more of the MVC system - model, view, controller. Your model layer would be all your db interfaces (selectUsers(...), updateUser(...)). Your view would take the output and render it somehow. Your controller ties the two, taking care of input/output manipulation and choices.

For your database stuff, you have your DB.pm, which is good. In the case you switch or want to use other DBs, you can swap this layer out with ease, keeping a consistent interace.

For my controler, I would take the input and tarnslate it into XML documents. XML is very portable. Not the uber most efficent way in terms of CPU cycles, but what you lose in performance, you gain in great modulariztion.

Using XSLT, you can then translate into PDF, HTML, WAP, CSV, TXT, since your XML document is a complete description of your data.

For the controler/decision making portion and the XSLT translation, there's a great tutorial at perl-xml.sourceforge.net

XML is slow to process - prototype your system. Using XML would be idiotic to do IPC between threads. The native forms are faster. Using it between systems is quite smart, especially foreign ones, ala web-services. In complex systems, it is also "good". Translating XML to any other formats is quite easy. Translating doc to applewrite format would be a pain. If the speed difference is negligible, I would go with an XML based solution.

XSLT is slow - Many web browsers support XSLT translation on the client end. It would be a matter of giving the XML and XSLT to the browser. For repeditive stuff, such as perlmonks comments, which have a definite pattern, the XML would be sent all the time as really small packets, but the XSLT once. Think of XSLT like CSS.

XML/XSLT are bloated. - mod_gzip is your friend. XML compresses quite well. Also, if you transmit the XSLT once and different XML packets using the same XSLT, you may not even need mod gzip since XSLT would be the work horse.

MVC is slower - MVC may be slower, but you reap the same benefits as you do from writting modules and functions and calling them. Yes, you have the overhead of a stack, but then again, if you want efficiency, you can always use ASM

What is using XSLT really buying you?

If you have the discipline to keep it clean, there is no reason to convert to XML only to have to introduce a new language and a lot of overhead. Instead you can construct the views in Perl, likely using the various templating modules to organize it.

If you do this, then you'll likely find no practical performance difference between MVC and any other approach.

Well, it provides a level of modularity. If I switch from perl, to c++, to java.. there are API's that deal with turning XML to XSLT. So if I have 100 templates, and decide to switch languages, I can do so with ease.

There are XSLT compilers, so you can gain some performance over ones that do a live string scan.

XML isn't always slow; Using SAX, it's quite fast. I'd suggest writing a SAX implemented XML parser and see for yourself. It's almost no different from a templating engine. And as I said before, XSLT/XML aren't always THE choice. It's A choice that can take some serious consideration.

New language? perl is your language, xslt would be your template language. How is it any different from using perl and HTML::Template or HTML::Mason? If your argument is against templating engines, yes, you now have HTML, (your templating engine), perl and your sql language. But that's how life is. You weigh out the advantages and make choices.


Play that funky music white boy..

Alright, so what I am getting (and DO correct me if I am wrong), is:

• Use an XML document as my template
• Extract text from the db
• Use a perl module to format the text/data against the XML

Close to correct?


"and I wonder, when I sing along with you if everything could ever feel this real forever? if anything could ever be this good again? the only thing I'll ever ask of you, you've gotta promise not to stop when I say 'when'", she sang

Use XSLT as your template engine, generate XML documents. That's how I've done some systems.

Play that funky music white boy..

You want an interface to the database. How much of the complexity of the database do you want your interface to give you access to? Do you want to be able to manipulate data in the database, or just display some of it? Do you wish to integrate this tool with the schema of the database? Do you wish to integrate constraints in some efficient way? And how should it scale? To updating 10's of millions of rows of data at once? To hundreds of simultaneous users? (That tends to conflict with manipulating lots of data at once.)

Until you nail down some of these significant details, it is hard for me to understand what you want to do. What you are describing could mean anything from Microsoft Access down to a module for displaying query result sets. I don't think that any one solution can effectively address all of the possible desires (certainly if I could dream of that solution, then I'd expect it to exist already).

Perhaps a better place to start is to think through some "use cases". Imagine that you had your module. How do you envision using it and what would the result be? Envision the usage in enough detail and you have a pretty good idea what the API should be. Envision what the result is in enough detail and how to start writing it will start falling into place. (Or, more likely, you will be able to recognize what you are looking for as being something that is already on CPAN.)

Well, to answer your question, I would like to write this site/set of perl scripts to be able to handle almost any amount of data it's given, maybe not quite like a corporate scale type thing, but something with say, 100+ users, a couple thousand messages, and many many many images and a lot of text.

I'd like to be able to use a module to use functions like update(), insert(), delete(), selectFrom(), etc, so I'd like to be able to display AND edit database data.

Mainly, I want a class that will pretty much handle all my database needs for me. A class that will be able to be accessed from the appropriate modules, such as a page module that would get the data from the database, and format it just so, along with a message script that would take the form data and insert it into the database as a new message, or a reply, or a user script that would update user info, or an admin script to delete, remove, edit, etc. messages and users.

Is that slighly more clear? I'm sorry for it being so vague, I was just trying to keep it general and open.

Thanks very much for all the help, just let me know what you need to know to help me.
dhoss

"and I wonder, when I sing along with you if everything could ever feel this real forever? if anything could ever be this good again? the only thing I'll ever ask of you, you've gotta promise not to stop when I say 'when'", she sang

By the way that you are generalizing your needs, it sounds like the module that I am studying: CGI::Application that combined with HTML::Template , would be able to do a lot in one single (and hidden) module.

The interesting thing of all this is that it is easy to follow an interactive dialog with every user and returning what is required in every case. The cgi script is very simple, and it only creates an instance of your CGI::Application module. I am planning to use it with a Session module. As if it were a commercial transaction. Just to learn!