Bringing Evo back to life again

• • 
  • 172 Posts
  TimGS Reply #351, 14 years, 4 months ago

  Quote from: microcipcip at May 14, 2012, 12:22 AM

  Something that I would like to see on next releases of MODX Evolution is an option to group Template Variables. Now you can group them by category, but these categories are NOT visibile when you edit a resource, so the user can't understand when one group finishes and when another starts. Sometimes, for example, I make set of TVs like this:
  

  TVimg1, TVtextarea1, TVdropdown1,
  TVimg2, TVtextarea2, TVdropdown2
  TVimg3, TVtextarea3, TVdropdown3

  
  
  And if the fields are similar it is difficult to recognize when you're editing the next set of TVs.
  
  I will add the design for some kind of "box grouping" on the Manager Theme. See the example in the attachment.
  
  What do you think?

  
  It should be an option.
  
  Some existing sites will have categories that are meaningful only to the developer, not the client/editor. They should be able to be hidden.
  
  It is possible to do this in ManagerManager but much of ManagerManager should IMHO be in the core of the manager anyway.
  
  -- Tim.
  
• • 
  • 1,098 Posts
  microcipcip Reply #352, 14 years, 4 months ago

  Quote from: TimGS at May 14, 2012, 09:21 AM

  It should be an option.
  
  Some existing sites will have categories that are meaningful only to the developer, not the client/editor. They should be able to be hidden.
  
  It is possible to do this in ManagerManager but much of ManagerManager should IMHO be in the core of the manager anyway.
  
  -- Tim.
  

  You're right, it should be an additional option different from current categories, because as you said, sometimes they're meaningful only to the developers. For example on Revolution Tabs are created automatically when you create categories, and I had to struggle a lot to make them look good on the Edit Resource page, I ended up making a lot of confusing categories names on the development side because of this.
  
  I think an extra for MM could be the right solution. I agree that MM should be in the core.
  
  BTW it seems that MM add a lot of javascript in the page. Isn't possible to make it work server side?
  Jertix.org -> Web Design & Development, Motion Graphics | Follow me on Twitter | MODx Tutorials (in Italiano) | MODx Snippets (English)
• • 
  • 2,314 Posts
  anonymized-26931 Reply #353, 14 years, 4 months ago

  microcipcip, sorry, this is the right one: http://modx.com/extras/package/tvcategorizedtabs
  
  (and another from Stefan: http://modx.com/extras/package/tvsontemplate)
• • 
  • 172 Posts
  TimGS Reply #354, 14 years, 4 months ago

  Quote from: microcipcip at May 14, 2012, 10:01 AM

  
  BTW it seems that MM add a lot of javascript in the page. Isn't possible to make it work server side?

  
  Thats why I think it should be in the core.
  
  ManagerManager uses JS because it is the only way of doing this without hacking the current core.
  
  Some thought should be given as to how this would work for the developer. Some would prefer a GUI and others will prefer a chunk of code as per ManagerManager. I prefer the latter as its then easy to just paste in some boilerplate code.
  
  You could even emulate ManagerManager's functions - but instead of these controlling the JS, they would control the HTML generated server side.
  
  -- Tim.
  
• • ☆ A M B ☆
  • 24,524 Posts
  sottwell Reply #355, 14 years, 4 months ago

  The whole problem with the Manager 'core' is that all the action pages are mixed HTML with inline PHP, so the form gets output in bits and pieces. The plugins can only modify the page before the form starts getting created, and after the form is created. There's no way to manipulate the form as it's being created, or to modify it in any way after it's output. That's why MM has to use Javascript to manipulate it all in the browser DOM.
  
  One of the major projects I'm working on is to re-write each of the manager action pages to be pure PHP, with the database info loaded into placeholders, and a tpl similar to eForm, Ditto, and Wayfinder, and the whole finished form finally echo'd or returned, just as the parser does for front-end pages. That way the various events will allow for actual manipulation of the data and forms being generated, the same way the documentObject array and documentOutupt variable can be manipulated for front-end pages at various stages of parsing.
  Studying MODX in the desert - http://sottwell.com
  Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
  Join the Slack Community - http://modx.org
• • 
  • 222 Posts
  Stefanie Reply #356, 14 years, 4 months ago

  I solved some of the problems mentioned by kp52 on page 35.
  
  The missing cache is solved by a changed gitignore, the other where some older code, that added a LIMIT where it should not at all, the other a function, that I declared private, but was in use, I changed the visibility to public.
  
  The translation issues will be done later on. I prefer to work on the format of the code and to add phpDocumentator tags now. My main goal is to get it all working before going for anything else.
  
  All corrections where done on the branch 1.1.dev.clearing-japanese.
  Gone away and found a better place to stay
• • 
  • 222 Posts
  Stefanie Reply #357, 14 years, 4 months ago

  Updated the GitHub repository:
  
  

  
  
  • Issues are available now
    
  • A wiki is available, everyone is allowed to read, but only the commiters are allowed to write. I don't want to end up with cleaning the wiki from Spam. If you want to share knowledge on the wiki, please create an account on [urlhttps://github.com/]GitHub[/url] and ask for permission in this forum.
  
  You find the issues at https://github.com/sjstoelting/evolution/issues and the wiki at https://github.com/sjstoelting/evolution/pulls
  

  .
  Gone away and found a better place to stay
• • 
  • 39 Posts
  Leif Reply #358, 14 years, 4 months ago

  Is there some kind of feature wish list?
• • 
  • 222 Posts
  Stefanie Reply #359, 14 years, 4 months ago

  Hi Leif,
  
  You can file an issue at GitHub, or just start a discussion in this thread. Features will be discussed in public.
  Gone away and found a better place to stay
• • 
  • 39 Posts
  Leif Reply #360, 14 years, 4 months ago

  I like to have two placeholders [*prev*] and [*next*] build right into the core. Pointing to the previous/next document based on the current folder.

This discussion is closed to further replies. Keep calm and carry on.