From: Bernard T. <bty...@tr...> - 2013-02-27 05:00:49
|
Hi, most answer to JP, but interesting as partial answer to jonny Sorry, but I think that there is a misunderstanding. > First thing. Major changes go in trunk. Not stable releases. I develop this solution to show it, and as I use 10.x (quite stable, regularly updates and checked) during a site development, I make some changes which can go sometimes farther than we could imagine to answer to the need expressed by a end user. By the way, I keep all minor changes to pack with a report. So I don't give any size neither make a classification for development, the question is : what I can show on my server is or is not an interesting solution to a real problem (may be the user don't works as it should...) Then major minor is a development classification and depends of strategy, I am not in. > Second. I do not think merging show and edit is a smart move. It does > not bring any usability advantage. If anything, always loading the edit > form in a separate tab increases the weight of the page and slows things > down, reducing the experience quality for the average reader. I have not said that I merged show and edit. It is exactly the contrary : I have used show as main shape to prepare most of data of the page at the end either : 1- I display the show 2- I display the edit mode both they generate a "mid" tiki.tpl To display edit mode there are more data to prepare it is done by a reduced "editpage" before calling the tpl. This separates show or edit in three parts : 1- header and info 2- content : show or edit 3- foot and categlist at execution edit is a little more heavy but quite the same as previously > Modularity should not be added by extracting code into include files, > especially not by adding more files into the root. There no more files at all and the edit generator have lost more than 40% regardless editpage. > I would support moving edit page to a set of services, splitting it into > preview, edit, and probably a few other things it does. I completely agree, this is the next step. There are four services : 1- Header information about a page and tocnav 2- show and 3- edit 4- Footer : informations about the page generally presented at the end but generated with (1) I tell that 2 and 3 can be served as "middle" content, so after edit it is only this part of the page which is updated (stream data type) > Just merging the files brings no technical benefit, other than > increasing the complexity of those already horrible files. Never spoke about merging files, but merge the functions as the way described. If it is done with 10.x is that it is the last that I can use to threat real data and look at users working and their remarks. End of main answer. You say "no need" I don't agree : 1- during edit before you had quite no informations about the page you have with this solution all the showpage information about the page 2- When working from admin-structure : check edit return to admin etc... often categories, {group} plugin, Copyrights and so on, you had a complex way (edit, save, show, admin-structure ) 3- When working from any other place else than from the wiki showpage, I try to make so that edit should be a service. It cannot really but, looks like. During the work I try to make the most simplifications as possible. I was saying, look at, is this ui offering an interesting way of work. After you will see what to do with (if interested look at the code, I don't propose more) Best regards Trebly I am sorry but it is always long, I don't at all tell the same content with precision in a shorter way. But it is so much time... lost ? On 26/02/2013 13:40, Louis-Philippe Huberdeau wrote: > First thing. Major changes go in trunk. Not stable releases. > > Second. I do not think merging show and edit is a smart move. It does > not bring any usability advantage. If anything, always loading the edit > form in a separate tab increases the weight of the page and slows things > down, reducing the experience quality for the average reader. > > Modularity should not be added by extracting code into include files, > especially not by adding more files into the root. > > I would support moving edit page to a set of services, splitting it into > preview, edit, and probably a few other things it does. > > Just merging the files brings no technical benefit, other than > increasing the complexity of those already horrible files. > > -- > LP > > On Feb 25, 2013 10:25 PM, "Bernard TREMBLAY" <bty...@tr... > <mailto:bty...@tr...>> wrote: > > Hi, > > I have published here a mail on 02/21 > > For future version ? : Wiki_pages show and edit - navigator - proposals > for simplifications > > This is done. > > I was not sure at all to reach the aim. > Because there are a lot of modifications on near 15 php, tpl, css, an > icon... from root but too smarty_tiki, > I have tested a lot and not found any problem, but may be there are > effects that I have not seen. I have to test all the translation > functions and the corresponding configurations of prefs. Too there are > prefs on wiki management to test. No reason to get problem I believe > > I think to four steps : > ----------------------- > 1- Who is ready to make an evaluation send a mail to get access to my > server as redactor > 2- After evaluation of ui, I will set all the component to the > experimental branch > 3- Who is concerned can either merge with his version and test, either > simply look at code. > 4- After the OK I commit the content of the experimental branch to 10.x > > What does this enhancement > -------------------------- > 1- From any point when you launches edit to a wiki page you reach an > enhanced page > a - looks like tiki-showpage for header > b- contains as center data the full editpage and all his functions > c- the end of page after special bottom for edit is the same as > showpage (index.php) > > 2- From this page you can launch : "view page" (not preview which is > a ever) > > 3- When you save you go to showpage on the current page (as previously) > but the edit button (actions in header - action icon edit in of > tiki-wiki_topline just replace the showpage by editpage > > What is the interest : > ---------------------- > 1- you can switch quickly from show-mode to edit mode without > environment change > 2- From wiki breadcrumb you can navigate and naturally edit immediately > and go back to navigation (previously editpage had no header to navigate > so to go back from editing a page to another, as described in my > previous mail, you had to launch again any access to edit from root > menu... this was not normal because they where thing to do it into page > edit but they could not function) > 3- From edit_mode enhanced option to reach back any point. > > How it is done : > ---------------- > Mainly : > 1- the tiki-editpage.php and .tpl are no more used (keep while exist > call not updated) > 2- The tiki-show_page.php is a little modified (name could be changed) > too tiki-editshow... > 3- tiki-editpage has been widely reduced to a tiki-editpage-v2-inc.php > and tpl > 4- if $_request['editpage'] new param in query is set to 'Y' index.php > will prepare the edit data before display > 5- tiki-showpage.tpl if edit_mode validated merges the edit display else > display data <div id="page_data"> as usual. > > Details : > --------- > 1- new href syntax from tiki-admin_structures.php > (structures_toc-leaf.tpl modified) > 2- new href syntax from pages list. > 3- new buttons in page edit mode : "Save and show" "Save and continue" > 4- option box (after a preview) : After save go to : admin-structures, > pages-list (this allow to make quickly changes in pages from > admin-structures : goto edit and return immediately to admin-structures > or to pages list > 5- Edit page buttons changed every where and syntax of href which is > always index.php?<page_name>&pagedit=Y (or N) > 6- New icon created "page-watch" which avoid confusions with "magnifier" > 7- Add icon button to go back to showpage mode from edit, because of > existence of new option "save but stay editing" > > > Evolution : > ---------- > The editpage data and the content $parsed to display will be exchanged > as blocks with the server replacing just the content. > Now when we flip from edit to show and versus we reload the whole page. > The flip will be immediate with this way of managed the content (note > same way as jqgrid). Change href of elements of page using DOM which > generates request for new content to server. Then send simply $parsed or > $midpage_edit, anything else. > > I can assure that it is sympathetic to have the whole top of wiki browse > (cats, tags, actions), all tiki-wiki_structure_bar.tpl and > tiki-wiki_topline.tpl during edition > and for the links and category management categobjects.tpl > > Best regards > > Trebly > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > TikiWiki-devel mailing list > Tik...@li... > <mailto:Tik...@li...> > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > > > > _______________________________________________ > TikiWiki-devel mailing list > Tik...@li... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > |