Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest sNews - sNews 1.7 - with its own forums - for discussion and user mods.

Pages: 1 [2]

Author Topic: New version / Opening the code to other developers?  (Read 515 times)

philmoz

  • High flyer
  • ULTIMATE member
  • ******
  • Karma: 161
  • Posts: 1988
    • fiddle 'n fly
Re: New version / Opening the code to other developers?
« Reply #15 on: February 14, 2013, 09:04:24 PM »


Better separation (articles in articles table, pages in pages table and so forth)

Articles are content, Pages are content. What differentiates them is how they are classified and output, so IMV should be in the same table. A different route to what you would be suggesting would be to simplify the articles table to have, simply, the content and then have a defining reference table that is used to access the content (articles) table.

content table
contentidtitlesefcontenttags

reference table
refIdcontentIdtypepublishedpublishedDateetc...
Logged
Of all the things I have lost, it is my mind that I miss the most.

nukpana

  • Hero Member
  • *****
  • Karma: 71
  • Posts: 663
Re: New version / Opening the code to other developers?
« Reply #16 on: February 14, 2013, 11:57:27 PM »


Better separation (articles in articles table, pages in pages table and so forth)

Articles are content, Pages are content. What differentiates them is how they are classified and output, so IMV should be in the same table. A different route to what you would be suggesting would be to simplify the articles table to have, simply, the content and then have a defining reference table that is used to access the content (articles) table.
If we are talking about simplifying and adding modularity, there needs to be separation. This isn't solely about the db tables, it is also the code base as well. It is unmaintainable continuing as it stands.
Logged

nukpana

  • Hero Member
  • *****
  • Karma: 71
  • Posts: 663
Re: New version / Opening the code to other developers?
« Reply #17 on: February 15, 2013, 12:08:23 AM »

More the "lets-put-as-much-as-possible-in-the-articles-table" approach, imo.
Right, and I can see where the initial thoughts were to have a small script that could do alot - fit similar pieces together (articles/pages/extras into one table) and simple theming (center() = public & admin routing, pagination, category article list, full page articles, pages, comment inclusion, etc etc).  The problem is when the site needs to grow, the system can't efficiently grow with it.
Logged

Fred K

  • Still trying to learn stuff
  • ULTIMATE member
  • ******
  • Karma: 130
  • Posts: 2728
    • Personal
Re: New version / Opening the code to other developers?
« Reply #18 on: February 15, 2013, 12:25:44 AM »

Articles are content, Pages are content. What differentiates them is how they are classified and output, so IMV should be in the same table. A different route to what you would be suggesting would be to simplify the articles table to have, simply, the content and then have a defining reference table that is used to access the content (articles) table.

Yes, true, and I'm not saying my suggestion is the best solution (I wouldn't know if it is - it may even be completely useless, for all I know), but I do feel that even though articles and pages both are content, they are content with different purposes. Look at the current articles() form, for example. The current output, even with the $_ID filter doesn't distinguish between content types, but oftentimes page output has different needs than article output and could/should therefore be treated differently. As in separately. Pages seldom need/want the infoline. Pages seldom need/want comments. etc. With better separation comes simpler handling. Obviously, even I can see it, the use of "type" in a reference table would allow more detailed control in an articles() function, but it would still be (I assume) a function that treats article and page content (more or less) the same. Instead we could have a simplified articles function just for articles and a simple pages function just for page output. Easier to maintain/develop/modify, easier to debug, etc. Not to mention simpler admin parts for each. At least, that's how I see it. But again, I might be falling off a cliff here... ;)
Logged

Fred K

  • Still trying to learn stuff
  • ULTIMATE member
  • ******
  • Karma: 130
  • Posts: 2728
    • Personal
Re: New version / Opening the code to other developers?
« Reply #19 on: February 15, 2013, 12:39:21 AM »

More the "lets-put-as-much-as-possible-in-the-articles-table" approach, imo.
Right, and I can see where the initial thoughts were to have a small script that could do alot - fit similar pieces together (articles/pages/extras into one table) and simple theming (center() = public & admin routing, pagination, category article list, full page articles, pages, comment inclusion, etc etc).  The problem is when the site needs to grow, the system can't efficiently grow with it.


Yup. And it's not just about site growth, it's also about changed demands in functionality. Every time I do an sNews site nowadays (both own and for others) the amount of modding because of functionality demands is growing exponentially. It's a long time since I put out an unaltered sNews site (apart from styling, that is). Even my own, modified baseline isn't enough anymore...
Logged

Keyrocks

  • Doug
  • ULTIMATE member
  • ******
  • Karma: 449
  • Posts: 6019
  • Semantically Challenged
    • snews.ca
Re: New version / Opening the code to other developers?
« Reply #20 on: February 15, 2013, 06:07:57 AM »

... even though articles and pages both are content, they are content with different purposes.

One of the conveniences I like with 1.7 is that we can edit an article and save it as a page with or without comments. It's also been relatively easy to modify the cats/subcats functions so that both article and page links are listed in cat/subcat menus. I don't know if separating articles and pages with separate functions and tables would make these two features more difficult to apply but I'd rather not lose them.  :)
Logged
Do it now... later may not come.
-------------------------------------------------------------------------------------------------
sNews 1.6 MESU | sNews 1.6 MEMU

nukpana

  • Hero Member
  • *****
  • Karma: 71
  • Posts: 663
Re: New version / Opening the code to other developers?
« Reply #21 on: February 16, 2013, 12:28:03 AM »

Articles are content, Pages are content. What differentiates them is how they are classified and output, so IMV should be in the same table.
Comments, categories, file uploads, ads, etc, etc are all content too if you are putting it in that perspective.

The reason why Articles, Pages & Extras are grouped together is because they share common attributes, but then again not really.  A page, as sNews defines it, does not need a category, nor a extraid, etc, etc. An article doesn't need a default_page, page_extra. Extra doesn't need keywords, etc. etc. I hope you are seeing the picture, where grouping everything together does not make sense to do and should be discouraged.

One of the conveniences I like with 1.7 is that we can edit an article and save it as a page with or without comments.
Thats cool that it can be done, but how many times would one do something like this - for example needing to change from a static page to a dynamic, time-lined article or reversing it? About Me (page) to Design/About Me (Article in Category). It's one of those user scenarios that may be one offs that could be excluded out of core functionality and into a module/plugin. These are the types of things that need to be discussed and rationalized.

It's also been relatively easy to modify the cats/subcats functions so that both article and page links are listed in cat/subcat menus. I don't know if separating articles and pages with separate functions and tables would make these two features more difficult to apply but I'd rather not lose them.  :)
I don't think that would be an issue, but it that something that is decided in the template and not in the core system?  See where the confusion is - you like the simplicity of the theming:
Quote
I also still appreciate the simplicity involved with theming the site with one template (index.php) file and one CSS file.
but in your user case scenario, it doesn't work for a "core" system function. It really should be regarded as a module/plugin that can be further manipulated in the template view on output, so it can be specialized for you - because each sNews system as it stands is a unqiue system that is incompatible with each other and incapable of future updates - Fred sums it up earlier:

Every time I do an sNews site nowadays (both own and for others) the amount of modding because of functionality demands is growing exponentially. It's a long time since I put out an unaltered sNews site (apart from styling, that is). Even my own, modified baseline isn't enough anymore...

This is when the the problem needs to be looked at at a core level - what needs to be done to allow a unmodified core that users can upgrade and can be extended if needed. The benefit here is that if the core can stand and need little maintenance, then you won't need a big "team" - let the community work through plugins and share accordingly.
Logged

Fred K

  • Still trying to learn stuff
  • ULTIMATE member
  • ******
  • Karma: 130
  • Posts: 2728
    • Personal
Re: New version / Opening the code to other developers?
« Reply #22 on: February 16, 2013, 04:47:14 PM »

This is when the the problem needs to be looked at at a core level - what needs to be done to allow a unmodified core that users can upgrade and can be extended if needed. The benefit here is that if the core can stand and need little maintenance, then you won't need a big "team" - let the community work through plugins and share accordingly.

Yup, well put. With sNews as it is today you basically have to modify the core file if/when you want to manipulate the output in some way. The core should ideally, as far as possible, be untouched (save for updates etc.)

Quote from: Keyrocks
It's also been relatively easy to modify the cats/subcats functions so that both article and page links are listed in cat/subcat menus. I don't know if separating articles and pages with separate functions and tables would make these two features more difficult to apply but I'd rather not lose them.

Personally I've never understood that use - a page assigned to a category is essentially, apart from the table position, an article after all. That doesn't mean it wouldn't still be possible to make a mod that does this, if needed.
Logged
Pages: 1 [2]