paging.cfc

Hello

I had to apply some formating things to paging.cfc. Is this plugin update save or will it be overwriten if an update takes place?

Many thanks

Cheers

Hi Martin–

I believe any changes to that file would get overwritten in an update. What kind of formatting changes did you need to add? Maybe they are something that would be helpful to integrate into what exists, or use it to provide a mechanism for customization.

Thanks!

  • Changed the english strings, e.g. “next page” to my language
  • Added a title attribut in the links e.g. “page 1”, “page 2”
  • Added an if-block <cfif totalPages neq 1>… to get rid of the paging, if we have only one page.
  • Changed the names of the CSS classes to match my generated styles.
  • Added some code to highlight the selected page.
  • Replaced the << and >> to symbols from Font Awesome.

The changes are related to my matter of taste and my CSS-Framework.

Cheers

Hi Martin–

I think these are really great ideas and could definitely be beneficial to others. Would you mind sharing what’ve you done so far?

Thanks!

Sure. But first in need to finish my theme, which will be the base for some projects. After everything is done, i will do some aftermath to document, what and which code I had to change or create new to get theme up and running.

Martin,

If you haven’t read any of my blogs or others on how to write modules, widgets and plugins to be used within ContentBox. Then I suggest making a trip over to these blogs first.

When using any of the ContentBox plugins, you are using what ContentBox has defined as global widgets to the system. Any changes you make effects every other theme / layout in ContentBox.

This is one of the things that I don’t like about ContentBox, something that I have asked for many times, where there is core and user defined widgets etc., that are not stored in the same location. As it stands now the only way to make changes to these widgets, is to copy it and rename it to something else or follow along with some of the blogs that I and others have read on creating modules and themes in ContentBox.

http://www.andyscott.id.au/blog/category/ContentBox

Will show all the blogs that I have written on ContentBox, from creating your own interceptors to creating your own themes, I think you will find a lot of useful stuff in some of them. If you have any questions or not sure on something, don’t hesitate to ask.

I found actually other code whch i have to change to my formating needs, e.g. the search form and search results. Mostly i have two choices:

  • Change the original widgets to my needs, knowing that an update needs some re-copy.
  • Building my own widgets, which results in having also my own CBHelper. I have already one, i call it “ThemeHelpers”, which supports my formatting stuff.

I think, it isn’t really possible to write layout independent widgets/plugins to support any CSS stuff. Or, if possible, the argument list to transport the CSS information to the widgets/plugins would be enormous and mostly nobody might understand and use it.

But and i think, we discussed this before: ContentBox could look into two separate locations for its stuff: The factoy folder(s) and project/customer based folder(s). It would look first in the project/customer folders. If the desired code ist there, it would take it, If not, it would take the factory code. Nothing really new, other apps are doing this already. But i like the concept.

Martin, it is possible to do anything you want…

My blogs talk about independent widgets and plugins and interceptors for themes, if there is something you are not understanding, please let me know.

As for locations, what ContentBox needs to do is inherit the external features of ColdBox. For example ColdBox has had the ability to have external views,handlers/plugins etc., this sort of thing would work well within ContentBox and is something that has escaped my logic of why it was all put in one location to begin with.

I know that 99.9% of users will not come across this, but when you start putting things like this onto forgebox or other distribution channels, you run the risk of very easily deleting and reprogramming a widget that breaks in every other theme. The same as being able to edit core widgets etc., in my eyes is something that should never be allowed under any cirumstances. It only takes one person to get the admin account and boom open access to core files and change them to spread what ever malicious content you want to spread.

But again ContentBox can do anything you want it to do, yes some of the things I blogged about requires a further understanding of ColdBox itself, but when you do understand it will open your eyes as to how powerful it all is.

ContentBox maybe at V1.6 and been around for a short time, but it is very powerful with what it has now.

Many thanks, i know how powerful ContentBox is. Only the programmer is the limit…

I agree, that manipulating a factory made plugin/widget must be avoided. I already started to write my own code dealing with the paging. After the ColdBox-Camp i will have more knowledge, which will open doors.

Cheers

same as being able to edit core widgets…

Are the widgets in the folder contentbox/widgets declared as core widgets? I think yes, but they are editable out of the Admin UI and these widgets will be updated, as seen in a patch.zip.

Maybe a big warning message in the widget editor would make sense: “Your edited widget might be overwritten in a future ContentBox Update”.

Or as Andy adviced: Leave the fingers from this stuf and create your very own widgets and/or plugins.

I’m asking myself, if somebody uses the build in widget editor anyway.

Cheers

I don’t, I think it is a useless feature. You can lock these down for your editors, but I still don’t think an Admin should have access to this stuff from the Administrator Dashboard.

Secondly, as you pointed out Martin if these change in the future they get overridden with the changes from the core update and why there should be a core and user widget area, because user widgets should never get updated unless you are updating that widget / module or whatever from an updated version of that widget etc.

This is one reason why I always create a module and stick these into that. I blogged these two articles.

http://www.andyscott.id.au/blog/extending-contentbox-with-modules-separate-to-contentbox

http://www.andyscott.id.au/blog/extending-contentbox-with-modules-separate-to-contentbox-part-ii

Because I got sick and tired of things being able to be updated in the system, the current ContentBox way meant that all my code would be viewable and modifiable in the dashboard. To prevent this from happening I ended up with the solution in those two blog posts.

These modules also now contain my patches to ContentBox, so that I don’t have to keep patching ContentBox on each release, although I did forget one which I blogged about yesterday.

That’s an interesting observation Martin. Maybe we need a way to distinguish what are core and custom. Maybe submit a ticket for evaluation. But yes, you are right, if you modify them, a patch could update them and you loose your changes there.

signature0.jpg

Luis F. Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Social: twitter.com/lmajano facebook.com/lmajano