Not yet, finishing some work with tables and fields and so on, just to get it perfect before going into the code for customizations

Cool!

Be interested to hear what you think.

Good luck,

Gez

I'm positive that it will be great, and i love the idea of having the WHERE clause being customized by the filtering

You got me confused for a moment, asking myself, "what filtering for the where clause?" but, you mean in my other post, right? j-cook.pro/forum/12-new-functionalities/...-import--export#4102

You got it right

My comments ...

Yes you can filter the results with the filters... easily.


GETTING THE DATAS :

Since I have been coding with Joomla, I have not been using native mysql_fetch_assoc
Does it means that the rows are called with a call at once ?
I mean how do it behav regarding the memory ?


The alternative I show you is using a PHP array storing all the requested rows, before to output. It can be heavy in memory for HUGE lists.
So I don't know with mysql_fetch_assoc, maybe it is better.


WRITE IN MODEL

You have all the tools to get an object list handling filters, pagination, acls, accesses, publish states, authoring, ...
It is called a model

Instead of puttin all added source in the helper, try to find the right place.
The right place is in the list model.

And if you want to apply theses features for all models, put this code in classes/jmodel.item.php, the superclass.

Eventually, in the prepareQuery() of the model to export datas, add a new context query. Spoken a lot of the forum. It is the only one function called for all SQL select queries.

If you want to export the current layout grid, you do not need to create a new SQL profile. Eventualy, switch the state var to avoid the pagination.

Again, all you need to know in Cook :
- prepareQuery() and profiles in it
- States vars

You can do want you want. That's almost it !

SYNTAX :

Long list of arguments is not very clean and problematic when you want to set up only the 9th var for example. An array of params, like JDom can do the job to switch the behaviors (download, overwrite, headers).
I think you can also pass theses arguments trough the states vars, because you are (now) in the model.


RENDERING THE OUTPUT :

Respecting the standards, you should put you file header and all what is relative to output in the VIEW. Even if it is not hml. It can be a RSS feed, it can be a file to download...all the outputs in the view.

I am wrong too in cook, because the indirect file access is written in a class, I found this more pluggable, independent. So, as you see, what is the best ?

Having a quite short and independant function in the model, without returning to the view is good also. Debate.

God... at this time of the night, this is just too much for me to understand

I think I am wrong.

You can put it in helper. It is maybe better, in that way you make it independent. Or a class file if it become more complex in future.

Anyway, you still use and play with a model instancied in your helper function.

Then, if you prefers mysql_fetch_assoc, let's arrange the model to work with it.
But as I told you it is a supposition about the memory. Must check.

I suppose it could be replaced with the loadAssocList ?

The idea if you have 1 000 000 000 records.
If you use mysql_fetch_assoc, I think it load only one row in memory, and subitly, you write in file.
The row memory is cleaned, and another row can be read and written in file, etc...

In the case you load the whole list, you must keep it in memory, until the export is finished.

I think for us, let's forget about this, but it is good to think about it later.

Having a full array of datas in memory is good also to permit calculations on it, or sorting, etc...

I vote for the classic $model->getItems()

Is this something that you think could be added to cook native with suggested limited functionality in the sandbox?

WOW ... all of this is so far over my head ... Wish I could understand.

It's not that difficult, honestly... If you follow my post for importing here: www.j-cook.pro/forum/9-coding-inside-you...porting-records#4072

and Exporting here: www.j-cook.pro/forum/9-coding-inside-you...mit=10&start=10#4099 you can't go far wrong.

You could even try it in a raw php file on your local server environment if you wanna test outside of your component. In your localhost www or htdocs, create...

NEVERMIND... Gimme ten mins, I'll throw the files up for you to download now...

Gez

sdm7001 wrote: Do as I do : pretend you understand

Hey @sdm7001,

OK, done! The package includes 3 files - csv_export.php, csv_import.php and functions.php

SETUP A LOCAL TEST

1. Download & unzip this package to result in a folder called csv-test
2. Drag it to the root of your joomla installation - [joomla-root]/csv-test
3. If you need any further info or instructions about the functions/arguments themselves, please read my posts from earlier in this thread although there are also pretty good comments in the php too
4. EDIT the file csv_import.php entering the 2 arguments into the function call (the file/path to the CSV you want to import & the name of the table you want to import the records to. Don't worry about handling connection to the DB - I imported joomla framework in the first couple of lines of functions.php
5. Similarly, edit the file csv_export.php to put in the arguments you require - i.e. the filename you want to output, table you want records from etc.

CALLING THE FUNCTIONS
Now you have the edited files in place, the next steps are really straightforward...

• IMPORTING
  1. Drop the CSV file that you wish to import into the csv-test directory
  2. Call the function by pointing your browser to the web http://root-of-your-joomla-site/csv-test/csv_import.php
  3. Check your database for the new records
• Exporting
  • Point your browser to http://root-of-your-joomla-site/csv-test/csv_export.php
  • Check the file in the directory you saved it to
  • Done

Hope this helps!

Gez