Skip to main content
Topic: Portal... let's talk about it (Read 6993 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Portal... let's talk about it

From time to time, a thought crosses my mind: let's fully integrate SimplePortal into the package and distribute it in one single entity.

What would you think about it?
Pros?
Cons?
Objections?

From my point of view, I think that within the pros there would be a much more complete and probably competitive package (people wouldn't have to download two things to get the whole thing at once). It would also provide most of the things necessary to the idea of the widgets I proposed a while ago without having to re-invent the wheel.
Among the cons I would include the usual problems arising from shipping a fairly big project in a single package (for example synchronized releases).
Bugs creator.
Features destroyer.
Template killer.

Re: Portal... let's talk about it

Reply #1

Not all people are using a portal, I don't think is a good idea to integrate it. Simple Portal is a good addon, maybe one of the most downloaded for smf,  and works great. Imo should remain as an addon and let developers concentrate more on forum software ;)

@emanuele if you have free time you can always try to get better the SP addon
http://www.elkarte.net/community/index.php?topic=2387.0
Just kidding ;)
sorry for my bad english

Re: Portal... let's talk about it

Reply #2

What features in SP would you want to see in Elkarte? I think that's the best place to start considering it. Otherwise, I think there is a ton of work that needs to be done to make Elkarte a better product on the backend first, without worrying about adding tons of new stuff.

Re: Portal... let's talk about it

Reply #3

Seems like a lot of work to maintain both packages. I see the benefits of not having to maintain the mod separately, but really I think it's better left as a mod. Especially if you guys get to the point where mods are just dropped into a directory.
Success is not the result of spontaneous combustion, you must set yourself on fire!

Re: Portal... let's talk about it

Reply #4

Get the gallery working first.  :D

Re: Portal... let's talk about it

Reply #5

SP is already an addon and I don't see why it is needed to be integrated at this stage. I agree that will be a lot more works for maintenance if both are integrated and distributed as an entity.

Re: Portal... let's talk about it

Reply #6

Quote from: Joshua Dickerson – What features in SP would you want to see in Elkarte?
Basically the whole framework for blocks and the pages.
Bugs creator.
Features destroyer.
Template killer.

Re: Portal... let's talk about it

Reply #7

To elaborate a bit more.

Template layers are one way to do things, but thinking about this, I started considering that use "blocks" would be a much better solution[1]to display pieces of "information" all around the page (for example, this quick reply, would be a block, the same for the linktree, etc.).

Pages are a commonly asked feature (even Jorin asked for the impressum page ;)), and starting from pages, including blocks, it could be possible to build some rather complex and nice thing (for example the statistics page, could be realized as a "page" and be fully customizable through the admin panel... yeah, I know I'm partially daydreaming[2], but... who knows.)
Actually, what I think would be wonderful, is a layout à la java, but probably it would be "slightly" overkill. :P
But I like to dream and one day I'll write one. 8)
Even though it's not really "day" at midnight :P
Bugs creator.
Features destroyer.
Template killer.

Re: Portal... let's talk about it

Reply #8

I get "pages" but what are blocks specifically? I know what the are from experience, but can you define them?

Re: Portal... let's talk about it

Reply #9

Quote from: emanuele – To elaborate a bit more.

Template layers are one way to do things, but thinking about this, I started considering that use "blocks" would be a much better solution[1]to display pieces of "information" all around the page (for example, this quick reply, would be a block, the same for the linktree, etc.).

Pages are a commonly asked feature (even Jorin asked for the impressum page ;)), and starting from pages, including blocks, it could be possible to build some rather complex and nice thing (for example the statistics page, could be realized as a "page" and be fully customizable through the admin panel... yeah, I know I'm partially daydreaming[2], but... who knows.)

One thing to consider is that if you add the possibility to attach blocks to anything, it will be much harder to theme afterwards. You would lock its HTML code within the block only, not accessed by a theme(possibly). In itself its not that bad..only doing CSS, but IMHO using layers is better since it promotes themes to change its appearance.

That said..the "normal" way of adding a left/right etc. container for the blocks are outdated("panels" in TP and SP I assume). Its far better, again IMHO :) to provide a grid system, where the content is just one "cell". It allows you to quickly change the grid when dealing with mobile devices and the user have more control of the "blocks" than before. The actual grid code is locked of course - but its CSS-based so its highly customizable still.

My apologies if I misunderstood you - maybe you were thinking in similar terms?
Actually, what I think would be wonderful, is a layout à la java, but probably it would be "slightly" overkill. :P
But I like to dream and one day I'll write one. 8)
Even though it's not really "day" at midnight :P

Re: Portal... let's talk about it

Reply #10

Quote from: Joshua Dickerson – I get "pages" but what are blocks specifically? I know what the are from experience, but can you define them?
http://simpleportal.net/index.php?action=forum <= what is on the left column: "User info", "Who's Online", etc., each one of these is a "block", also the ADS and the welcome message are blocks.

Quote from: bh.kristiansen – One thing to consider is that if you add the possibility to attach blocks to anything, it will be much harder to theme afterwards. You would lock its HTML code within the block only, not accessed by a theme(possibly). In itself its not that bad..only doing CSS, but IMHO using layers is better since it promotes themes to change its appearance.
Not really. ;)
I already played with SP and changed it so that each block is separated in its own file:
https://bitbucket.org/spuds_/elk_simpleportal/src/197bd5e1c0f259effb83d8c56954bfedbd39bc7e/subs/spblocks/?at=master
and inside each of them the "source" part is isolated into a class, and the theming is in "normal" template_* functions:
https://bitbucket.org/spuds_/elk_simpleportal/src/197bd5e1c0f259effb83d8c56954bfedbd39bc7e/subs/spblocks/Articles.block.php?at=master
Actually, it's not yet perfect, because to override the template is not enough to load the proper file, but it's a first step (even the blocks do not use yet the classes directly, but a wrapper function that instantiate and class the appropriate method).

Quote from: bh.kristiansen – That said..the "normal" way of adding a left/right etc. container for the blocks are outdated("panels" in TP and SP I assume). Its far better, again IMHO :) to provide a grid system, where the content is just one "cell". It allows you to quickly change the grid when dealing with mobile devices and the user have more control of the "blocks" than before. The actual grid code is locked of course - but its CSS-based so its highly customizable still.
That would likely be a good idea as well, I'm playing a bit with grids (see the tentative I did with bootstrap in the past and with purecss now) but being a little terrible in theming my results are just indicative. :P
Bugs creator.
Features destroyer.
Template killer.

Re: Portal... let's talk about it

Reply #11

Oh, a grid should really not be one already made, they add way too much unused stuff - same way I've come to appreciate the advantages in NOT using  Mootools or JQuery. Because the things - IMO anyway - you need from the framework is not that harder to make in regular js. Also, if that framework is there to accomdate possible use of the many plugins - how many times do you need to that special lightbox feature lol. :P

But back to grid frameworks- there are some nice minimal ones out there..but homegrown is still better. You can make exactly what you need and be done with it. Bootstrap is good in making everything *work*..but it also adds stuff you don't need. I find taking the time to learn what it does, use the relevant parts and work from there, is far better. Which is alsowhy I have started from scratch on default themes in SM2/2.1 a few times..its an monolithic piece of stylesheet lol and I have no time to learn its "inner" workings. I have to say Elkarte isn't faring much better..but it is what it is. :)


Ah, so the blocks are object-based, including its (framing) HTML output?

Re: Portal... let's talk about it

Reply #12

Quote from: bh.kristiansen – Bootstrap is good in making everything *work*..but it also adds stuff you don't need. I find taking the time to learn what it does, use the relevant parts and work from there, is far better.
I agree on bootstrap, too big of a beast to deal with. I am looking for a very bare one, mainly because if it is already ready, "I" don't have to spend time on it. :P
On the JS... yes and no. Yes, you can do it yourself, but several things are not that easy to do, and jQuery is another beast to deal with. The advantage of frameworks (usually) is that those with less experience can have something "easy to use" without having to learn it from scratch (e.g. the whole smc_* functions around in SMF/Elk code that are not really the best thought pieces of code available, and I provided my good share of niceties to them). But okay, that's for another topic. :P

I find another value in using not self-made stuff: it helps me seeing where the problems are.

Quote from: bh.kristiansen – Which is alsowhy I have started from scratch on default themes in SM2/2.1 a few times..its an monolithic piece of stylesheet lol and I have no time to learn its "inner" workings. I have to say Elkarte isn't faring much better..but it is what it is. :)
I agree, in fact any time I start playing with a framework, the first thing I do is clean up completely the css.

Quote from: bh.kristiansen – Ah, so the blocks are object-based, including its (framing) HTML output?
The output is more "array-based", in the sense that the data to generate the block template is passed to the template as argument of the function in the form of an array. That way, the template doesn't have to deal (too much) with globals, see:
https://bitbucket.org/spuds_/elk_simpleportal/src/197bd5e1c0f259effb83d8c56954bfedbd39bc7e/subs/spblocks/SPAbstractBlock.class.php?at=master
the HTML is outputted when the "render" method is called, the render method calls the template function passing to it the array of data built by the setup method of each block.
Another thing I plan to do, is separate different "views", for example:
https://bitbucket.org/spuds_/elk_simpleportal/src/197bd5e1c0f259effb83d8c56954bfedbd39bc7e/subs/spblocks/Recent.block.php?at=master
instead of having the three situations (no data, compact, full) in a single function, I want to reach a point where there are three different functions to deal with the three of them.
Bugs creator.
Features destroyer.
Template killer.

Re: Portal... let's talk about it

Reply #13

May be, at this point, offering two downloads will be helpful to people realize the actual potential of ElkArte. One with just forum and forum + portal. It would be also nice to " Suggest " addons which can add interesting features through ACP.

Re: Portal... let's talk about it

Reply #14

Quote from: emanuele –
Quote from: bh.kristiansen – Bootstrap is good in making everything *work*..but it also adds stuff you don't need. I find taking the time to learn what it does, use the relevant parts and work from there, is far better.
I agree on bootstrap, too big of a beast to deal with. I am looking for a very bare one, mainly because if it is already ready, "I" don't have to spend time on it. :P
On the JS... yes and no. Yes, you can do it yourself, but several things are not that easy to do, and jQuery is another beast to deal with. The advantage of frameworks (usually) is that those with less experience can have something "easy to use" without having to learn it from scratch (e.g. the whole smc_* functions around in SMF/Elk code that are not really the best thought pieces of code available, and I provided my good share of niceties to them). But okay, that's for another topic. :P

I find another value in using not self-made stuff: it helps me seeing where the problems are.

Quote from: bh.kristiansen – Which is alsowhy I have started from scratch on default themes in SM2/2.1 a few times..its an monolithic piece of stylesheet lol and I have no time to learn its "inner" workings. I have to say Elkarte isn't faring much better..but it is what it is. :)
I agree, in fact any time I start playing with a framework, the first thing I do is clean up completely the css.

Quote from: bh.kristiansen – Ah, so the blocks are object-based, including its (framing) HTML output?
The output is more "array-based", in the sense that the data to generate the block template is passed to the template as argument of the function in the form of an array. That way, the template doesn't have to deal (too much) with globals, see:
https://bitbucket.org/spuds_/elk_simpleportal/src/197bd5e1c0f259effb83d8c56954bfedbd39bc7e/subs/spblocks/SPAbstractBlock.class.php?at=master
the HTML is outputted when the "render" method is called, the render method calls the template function passing to it the array of data built by the setup method of each block.
Another thing I plan to do, is separate different "views", for example:
https://bitbucket.org/spuds_/elk_simpleportal/src/197bd5e1c0f259effb83d8c56954bfedbd39bc7e/subs/spblocks/Recent.block.php?at=master
instead of having the three situations (no data, compact, full) in a single function, I want to reach a point where there are three different functions to deal with the three of them.

I agreed, the js used in SMF is a little.. strange. It uses prototypes, and thus sort of mimicks what JQuery etc. do. I guess its a matter of preference, the one that wrote most of it, had maybe a inclination for that code style lol. I like plain js functions that do exactly what they are supposed to.

A little more on the CSS bit..I can certainly understand the need for a big stylesheet - if the templates are quite unique you want total control, every little bit put into the stylesheet. But who does that help, really? Not the themer, they are too afraid to change anything beyond what they "know". Not the user..they don't look at it anyway(but they do feel it when having to dl the 100k+ file on their mobiles ;) ) ..so I guess..the dev? So its really more a question of having a good base: the templates themselves. If theya re simple enough, the basic CSS can be simple, and custom themes would be the ones to be complex. Not the other way around.

Quote from: meetdilip – May be, at this point, offering two downloads will be helpful to people realize the actual potential of ElkArte. One with just forum and forum + portal. It would be also nice to " Suggest " addons which can add interesting features on ACP.
It sounds nice..but as always: someone got to code it :)