Welcome Guest, Not a member yet? Register   Sign In
Design Logic Help Requested
#11

(07-13-2016, 01:00 PM)mwebdesign Wrote: Hey @cartalot...I just read what I believe to be "the thread on this board about the autocomplete file" that you mentioned above. I saw that you contributed a autocomplete config file that was working for you. I've copied it over to see if it's something that might be helpful for me, but I thought I'd ask if you had made any significant changes/improvements to the file since posting it. Do you think your solution has any specific pitfalls I should watch for? Or have you found any other sources that you think work better?

the only drag is that you have to put in your model names like in the example. otherwise its really awesome.

(07-13-2016, 01:00 PM)mwebdesign Wrote: Also, in response to your final paragraph (which I seem to have missed earlier)...I know that CI documentation talks about moving the Application folder, but is there much about making a multiple application folder structure? Either in CI Docs or elsewhere that you know of? Of course, I can google this and that might answer my prematurely asked question, but if you have any input, I'd certainly take it in.

Some people get in this mode where they think the application folder has to be named 'application', and the system folder has to be named 'system'. This is even implied in the docs for upgrading. The main index.php file is where the file path for the application and system folders are. So you can go in that file, and change those settings. Then you can name your system folder something relevant like "system306" and your application folder "alphajuly2016" .

Then by creating a folder - with the main index.php file inside of it - that version of the application is directly available. So like a folder called 'alpha' - you set which system and application folder its using - then example.com/alpha will pull up that version. example.com/beta can pull up the beta version. and you can link between the two of them.

So then for example - if you have a bunch of public website functionality. And an admin area with completely different functionality. There is no reason they need to be sharing the same application folder - and there are many reasons why they should not be. Similar if you are building something - when you have something stable you can split it off. And then when you are working in your alpha folder and you do something to a route file that kills the application - you have not affected your beta version because its in a completely separate application folder.

I strongly support you dumping whatever 'addition' to codeigniter and learning how to use the framework as it is. There are few to none really great codeigniter tutorials out there because they are created in a hurry by people trying to teach one point. Developing a maintainable complex application is completely different. As soon as you add some 'custom' library etc to 'make things easier' you have added another layer of complexity (and confusion). Don't worry about being 'dry' or saving a line of code - make things as readable as possible. Again the most helpful lessons i've gotten have been from Robert Martin Clean Code lectures.
Reply
#12

(07-13-2016, 01:01 PM)PaulD Wrote: WireDesignz HMVC might be useful for you. You can keep all your separate apps in different folders (each with their own views and controllers).

Your 'main' app would just have to deal with permission to access, and calling the separate controllers within the HMVC framework.

Will make testing much easier, keep separation for your apps and it is very robust once you get the hang of it. Building an app like this on the back of a codecanyon example is not a great idea, should definitely be doing this from scratch.

You should also move the settings for each module into their own tables. Much easier to control that way. So module 'projects' reads 'project settings' from a projects_settings table. Much cleaner.  

My only advice from a job perspective is to be careful. Your desire for clean lovely code for good reasons may not be shared by your company if they already have code that works. They may be much more along the lines of 'if it aint broke dont fix it', rather than taking the full brunt of the blame for every limitation, bug or issue that arises in the future. Working with the disastrous code at least protects you from the point of view that 'its not your fault, it was how the code was designed in the first place'. And they may not be in a position to wait months and months for your version to come up to production level.

Of course I do not know what your remit or job description is, but a plan moving forward might be to work on both, the live stuff with support, bug fixes and improvements, whilst developing the new version when time allows. It sounds to me like your company was never into making beautiful code if all this is a revelation to them. And your direct report, who is currently understanding and listening, may be saying all sorts of things behind closed doors with her boss.

Good luck,

Paul.

Hi Paul, and thank you for your advice! I will take a look at WireDesignz HMVC as you suggested, but I feel like the solution you're suggesting might be a little more structure than I should use. You see, there's about 1000 apps based off of the main template app!

Unfortunately, they also don't want me changing the database structure because there is a sort of api that's running on it at the moment (for the ~1000 apps). Believe me when I say that I realize how crazy this all sounds and I appreciate every one of your (all of your) job-focused tips. They're all pretty spot on for things I need to be careful about! One thing I should clarify is that they don't have something that is working right now for the user base that I am developing this application. They only have something working for devs, and it is not acceptable to try and utilize it for the clients. They did have a half-built version of what I am doing, but it never worked (and is an even bigger mess than the dev version that does work).

Also, they are still a very small company in a sense. Very close to being "just moved out of the garage" size and while they're growing fast, they're mostly still a couple developers who've been piecing it together as they go!
Reply
#13

(This post was last modified: 07-13-2016, 05:13 PM by mwebdesign.)

(07-13-2016, 02:47 PM)ivantcholakov Wrote: @mwebdesign

Have a look at this project of mine (The MIT license): https://github.com/ivantcholakov/starter...-edition-4
If you think that it could be useful, enable receiving private messages in your profile in this forum and send me a private message. I will give you for free source to a small CMS built on top of this starter. I think, it will give you an idea how you could structure your code with scalability in mind, without much talking. It would not fit exactly to what you need, some features you should port/write alone, but at least you will start at a higher level.

But honestly, I still feel skepticism. I hope I am wrong.

@ivantcholakov

I've enabled private messages in my profile, but I'm not sure how to send one to you. I would love to see what you have come up with. I'm not so novice of a programmer that I can't recognize and utilize parts of good code when I see it!

Also, I understand your skepticism. I hope you are wrong as well Wink

Since most of this thread has been conversation with no code (on my part), I wanted to post what I've been working on today and get feedback from you guys, if that's cool. Plus, I feel like it's only fair...I don't want you guys thinking you're wasting all this good advice on someone who's completely oblivious. (so if my code looks like I'm completely oblivious, please let me know!!)

So, I have a "Version" controller with a 'view' method, as follows: (it's a bit messy, but that's mostly because I'm still figuring it all out)
PHP Code:
public function view($versionid "") {
 
       if(empty($versionid)) $this->template->error(lang("error_51")); //invalid profile
 
       $version $this->apps_model->get_version_information($versionid);
 
$feature_array $this->features_model->get_features_by_version_id($versionid);

 for(
$i 0$i count($feature_array); $i++){
 
$json json_decode(json_encode($feature_array[$i]), true);
 
$tempFeature = new Feature();
 
$tempFeature->setBasics($json['feature_id'], $json['display_type'], $json['detail_display_type'], $json['display_order'], $json['name'], $json['feature_type'] );

 if(isset(
$json['image'])){
 
$tempFeature->setImage($json['image']);
 }

 if(isset(
$json['parent_id'])){
 
$tempFeature->setParent($json['parent_id']);
 }
 
//
 
$test_array[$i] = $tempFeature->getFeatureInfo(1);
 }

 
$featureFam = new $FeatureFamily();

 
$versionSettings json_decode($version->settingstrue);

 
       $this->load->view("versions/view.php", array(
 
"features" => $tempFeature,
 
"test" => $test_array,
 
"version" => $version,
 
"versionSettings" => $versionSettings
 
));
 
   

I'm struggling with exactly how to work with the JSON data that I pull from the db...but I'll eventually figure that out!

I then have 2 libraries (is this the best place to put this logic? I wasn't sure) called "Feature" and "FeatureFamily" which handle individual feature logic and a block of features, respectively (...i plan to rename FeatureFamily to FeatureBlock actually)

These are basically following along the Composite Design Pattern examples I found and aren't fully functional yet, but they're getting closer.

Feature library:
PHP Code:
class Feature extends AppBuild
{
 private 
$feature_id;
 private 
$display_type;
 private 
$detail_display_type;
 private 
$display_order;
 private 
$name;
 private 
$feature_type;

 private 
$settings// separate...? FeatureColorSettings class
 
private $image// if relavant
 
private $parent_id//if relevant

 
public function setBasics($feature_id$display_type$detail_display_type$display_order$name,$feature_type) {
 
$this->feature_id $feature_id;
 
$this->display_type $display_type;
 
$this->detail_display_type $detail_display_type;
 
$this->display_order $display_order;
 
$this->name $name;
 
$this->feature_type $feature_type;
 }

 public function 
setImage($image){
 
$this->image $image;
 }

 public function 
setParent($parent_id){
 
$this->parent_id $parent_id;
 }

 public function 
setSettings($settingsArray){
 
              //...still working on
 
}

 function 
getFeatureInfo($featureToGet) {
 if(
== $featureToGet){
 return 
$this->name" as feature type: " .$this->feature_type"<br>";
 } else {
 return 
FALSE;
 }
 }

 function 
getFeatureCount() { return 1; }
 function 
setFeatureCount($newCount) { return FALSE; }
 function 
addFeature($oneFeature) { return FALSE; }
 function 
removeFeature($oneFeature) { return FALSE; }


FeatureFamily library:

PHP Code:
class FeatureFamily extends AppBuild
{
 private 
$features = array();
 private 
$featureCount;

 public function 
__construct() {
 
$this->setFeatureCount(0);
 }

 public function 
getFeatureCount() {
 return 
$this->featureCount;
 }

 public function 
setFeatureCount($newCount) {
 
$this->featureCount $newCount;
 }

 public function 
getFeatureInfo($featureToGet) {
 if (
$featureToGet <= $this->featureCount) {
 return 
$this->features[$featureToGet]->getFeatureInfo(1);
 } else {
 return 
FALSE;
 }
 }

 public function 
addFeature($feature) {
 
$this->setFeatureCount($this->getFeatureCount() + 1);
 
$this->features[$this->getFeatureCount()] = $feature;
 return 
$this->getFeatureCount();
 }

 public function 
removeFeature($feature) {
 
$counter 0;
 while (++
$counter <= $this->getFeatureCount()) {
 if(
$feature->getFeatureInfo(1) == $this->features[$counter]->getFeatureInfo(1)) {
 for (
$x $counter$x $this->getFeatureCount(); $x++) {
 
$this->setFeatureCount($this->getFeatureCount() - 1);
 }
 }
 return 
$this->getFeatureCount();
 }
 }


Oh, and there's also the abstract class AppBuild...although I'm not 100% sure on how useful this is:

PHP Code:
abstract class AppBuild {
 
   abstract function getFeatureInfo($previousFeature);
 
   abstract function getFeatureCount();
 
   abstract function setFeatureCount($new_count);
 
   abstract function addFeature($oneFeature);
 
   abstract function removeFeature($oneFeature);


The view file (stupidly dubbed "view" at the moment) is just var dumping the results so I can tell they're not empty.

Lastly, to give you guys a taste of what an actual Feature object looks like...Here is 1 of my "Feature/Object.php" files...which I've done nothing with except declare all the appropriate properties for each one...

PHP Code:
class ButtonPageFeature
{
 public 
$typeCode 2;
 public 
$supportedDisplayTypes = array(
 
'1' => 'Home Screen',
 
'2' => 'Menu Item',
 
'5' => 'Top Content',
 
'6' => 'Bottom Content',
 
'8' => 'Inline by Position',
 );
 public 
$supportDetailDisplayTypes = array(
 
'0' => 'None',
 
'1' => 'Normal',
 
'2' => 'Full Screen',
 );
 protected 
$settings// EXTEND FEATURE TO GET THESE?
 
protected $displayType;
 protected 
$detailDisplayType;
 protected 
$displayOrder;
 protected 
$name;
 protected 
$parentId;
 protected 
$active;

 protected 
$show_title//bool
 
protected $default_view// string 'list_view' or 'tile_view'
 
protected $list_view// object ->settings for list view or null
 
protected $tile_view// object ->settings for tile view or null

 
public $isComposite TRUE;


I'd love to hear any thoughts on if you think I'm way off track here. I feel like I should be able to pull all the data in from the db for 1 full app, build out the features of that app and place them in the appropriate feature blocks, (possibly utilizing an object pool or repository for some of this) - figure out a nice point and click compilation of (basically) rectangles inside an phone screen mockup for the users to click on, see appropriate options, and make changes. Of course, then I'm at the point where I need to figure out how to register those events and log the changes...but that's the next chapter!

(PS: don't pay too much mind to the actual data I'm returning from the libraries...I'm just throwing a couple of the properties back so I can see that the setting and getting of them is actually working. I've basically just started on the FeatureFamily functionality...if that wasn't already obvious!)
Reply
#14

oh! and keep in mind that I hadn't really received and started TAKING any of your all advice whilst working on the code I just posted!!
Reply
#15

(07-13-2016, 03:52 PM)cartalot Wrote:
(07-13-2016, 01:00 PM)mwebdesign Wrote: Hey @cartalot...I just read what I believe to be "the thread on this board about the autocomplete file" that you mentioned above. I saw that you contributed a autocomplete config file that was working for you. I've copied it over to see if it's something that might be helpful for me, but I thought I'd ask if you had made any significant changes/improvements to the file since posting it. Do you think your solution has any specific pitfalls I should watch for? Or have you found any other sources that you think work better?

the only drag is that you have to put in your model names like in the example. otherwise its really awesome.

(07-13-2016, 01:00 PM)mwebdesign Wrote: Also, in response to your final paragraph (which I seem to have missed earlier)...I know that CI documentation talks about moving the Application folder, but is there much about making a multiple application folder structure? Either in CI Docs or elsewhere that you know of? Of course, I can google this and that might answer my prematurely asked question, but if you have any input, I'd certainly take it in.

Some people get in this mode where they think the application folder has to be named  'application', and the system folder has to be named 'system'. This is even implied in the docs for upgrading. The main index.php file is where the file path for the application and system folders are. So you can go in that file, and change those settings. Then you can name your system folder something relevant like "system306" and your application folder "alphajuly2016" .

Then by creating a folder - with the main index.php file inside of it - that version of the application is directly available. So like a folder called 'alpha' - you set which system and application folder its using - then example.com/alpha will pull up that version. example.com/beta can pull up the beta version. and you can link between the two of them.

So then for example - if you have a bunch of public website functionality. And an admin area with completely different functionality. There is no reason they need to be sharing the same application folder - and there are many reasons why they should not be. Similar if you are building something - when you have something stable you can split it off. And then when you are working in your alpha folder and you do something to a route file that kills the application - you have not affected your beta version because its in a completely separate application folder.

I strongly support you dumping whatever 'addition' to codeigniter and learning how to use the framework as it is. There are few to none really great codeigniter tutorials out there because they are created in a hurry by people trying to teach one point. Developing a maintainable complex application is completely different. As soon as you add some 'custom' library etc to 'make things easier' you have added another layer of complexity (and confusion). Don't worry about being 'dry' or saving a line of code - make things as readable as possible.  Again the most helpful lessons i've gotten have been from Robert Martin Clean Code lectures.

Sweet!! I have just started my new build with a complete new download and install of CI. I've also been skimming over all of the documentation as I go (in case I missed something major) and with just the few little tests I've run, I'm already loving that autocomplete file! The only thing I've come across (in my like...10 minutes of playing around before leaving the office) is that it still hates my view files. :/ but that's the least of my worries.

I'm loving this idea of restructuring the application/system folders to a more functional setup! I'm definitely going to implement this (especially the "beta branch" concept as I tend to break all my routes right before an important meeting where I have to show what I've been up to!)

I've actually heard many recommendations for Robert Martin, but they've all pointed toward his book(s) and I had never thought to look him up on YouTube so that is on the top of my "to do" list to start watching those!
Reply
#16

(07-13-2016, 03:52 PM)cartalot Wrote: ...
Some people get in this mode where they think the application folder has to be named  'application', and the system folder has to be named 'system'. This is even implied in the docs for upgrading. The main index.php file is where the file path for the application and system folders are. So you can go in that file, and change those settings. Then you can name your system folder something relevant like "system306" and your application folder "alphajuly2016" .

Then by creating a folder - with the main index.php file inside of it - that version of the application is directly available. So like a folder called 'alpha' - you set which system and application folder its using - then example.com/alpha will pull up that version. example.com/beta can pull up the beta version. and you can link between the two of them.

So then for example - if you have a bunch of public website functionality. And an admin area with completely different functionality. There is no reason they need to be sharing the same application folder - and there are many reasons why they should not be. Similar if you are building something - when you have something stable you can split it off. And then when you are working in your alpha folder and you do something to a route file that kills the application - you have not affected your beta version because its in a completely separate application folder.
...

Hey, can you help clarify this for me? I want to get this "alpha" "beta" structure set up from the get go so I know how it all works down the line. I'm basically going about it exactly as you've mentioned above, but I'm missing something when it comes to making the "alpha" folder with the main index.php inside of it. Is the only thing inside the "alpha" folder the index file....or is the 'alphajuly' application directory in there as well? If I'm moving the main index file...doesn't something else have to point to where that is? is there also a "beta" folder with an index.php file pointing to the "betawhatever" application directory? And is there a reason that I would need multiple systems folders? ie: one for the beta version and another for the alpha version, or am I looking at that all wrong? Oh, and I'm thinking I probably need to have a .htaccess file that matches each of these as well?

Sorry if I sound like a lost puppy on this!

In the documentation (that I obviously missed my first time around...) it states that in order to support a multiple application structure...to basically just nest everything that is inside the application folder inside a subfolder (and then point to one or the other in the main index.php...I can see how that might work too, but I'm curious about your structure and would love to gain some more comprehension when you have a moment!

Thanks so much!
Reply
#17

Best thing right now is to get comfortable with CodeIgniter and learn it well, we will all be here to help you out when needed.
What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )
Reply
#18

You don't need to nest the applications within one directory, it's just one possible option. You just need to make sure all of the paths in each application's index.php file point to the correct directories (you can even have multiple CI installations, if necessary, though that should be a rare requirement), and you can move your index.php file, too (for instance, into a public directory).

Personally, I use some extensions on top of CI (Bonfire: https://github.com/ci-bonfire/Bonfire ), so my directory structure looks something like this:
- application
- bonfire
- /ci3
- public
- /index.php

I have some other directories for Composer and may not use exactly those names, but this is more or less the way it's structured. The important part is that the paths in that index.php file point to the right place, which lets you put your system, application, and views just about anywhere you'd like.

I'm considering separating some of my existing applications into their own application directories, which might look something like this:
- application
- another_application
- app_three
- bonfire
- /ci3
- public
- /index.php
- public2
- /index.php
- public3
- /index.php

The reason my system directory is named "ci3" instead of "codeigniter" or "system" is because my site was originally built on v2.x of CodeIgniter, so, for some period of time I had a "codeigniter" directory, which held the CI2 system directory, and two sites using a shared application directory, but separate system and public directories, so I could test my changes until the site was completely functional in v3.

So, the system is relatively flexible, it's usually just a matter of checking your work.
Reply
#19

(This post was last modified: 07-14-2016, 11:24 AM by cartalot.)

(07-13-2016, 06:58 PM)mwebdesign Wrote: Hey, can you help clarify this for me? I want to get this "alpha" "beta" structure set up from the get go so I know how it all works down the line. I'm basically going about it exactly as you've mentioned above, but I'm missing something when it comes to making the "alpha" folder with the main index.php inside of it. Is the only thing inside the "alpha" folder the index file....or is the 'alphajuly' application directory in there as well? If I'm moving the main index file...doesn't something else have to point to where that is? is there also a "beta" folder with an index.php file pointing to the "betawhatever" application directory? And is there a reason that I would need multiple systems folders? ie: one for the beta version and another for the alpha version, or am I looking at that all wrong? Oh, and I'm thinking I probably need to have a .htaccess file that matches each of these as well?

so the most secure way, and i think they are finally going to start suggesting this in version 4 - is to have your application and system folders 'above' the public html root folder. so for example (this is messy but hopefully its clear)

Code:
alpha001  /public_html/
betajuly    /public_html/
system306/public_html/
             /public_html/alpha/index.php
             /public_html/beta/index.php
   
and then for example in the index.php file in your alpha folder

PHP Code:
$system_path '../../system306';
$application_folder '../../alpha001';

// you can also set your base url in the index.php file
// this makes it much easier when using different versions
$assign_to_config['base_url'] = 'https://example.com/alpha'

Then if you always use base_url for your css, image, etc links - they will always work.
This is also a reason to always use codeigniter form helper for your form open -
because the url will always be correct . And yes your different application folders can point to the
same system folder. Conversely you can test out a newer version of the system on your alpha, etc.
Reply
#20

(07-13-2016, 01:01 PM)PaulD Wrote: WireDesignz HMVC might be useful for you. You can keep all your separate apps in different folders (each with their own views and controllers).

Your 'main' app would just have to deal with permission to access, and calling the separate controllers within the HMVC framework.

Will make testing much easier, keep separation for your apps and it is very robust once you get the hang of it. Building an app like this on the back of a codecanyon example is not a great idea, should definitely be doing this from scratch.

You should also move the settings for each module into their own tables. Much easier to control that way. So module 'projects' reads 'project settings' from a projects_settings table. Much cleaner.  

Good luck,

Paul.

Paul! I finally checked out WireDesignz HMVC at the end of last week, and I am so very happy with it!! It is working out perfectly! Thank you so much for directing my attention that way. I think that this modular approach is perfect and aligns well with the way the databases are put together already. Unfortunately...I can't separate the "settings" into their own tables. Believe me, I know that would make a boatload more sense, but they are basically hooked on keeping them the way they are. (it's already driving me batty that all the tables are named in singular and every ID field matches it's table....ie: 'feature_id' instead of just ID).

Anyway, I wanted to let you know that I've already gotten so much further with HMVC than I had previously. That's not to say I have more of my project completed, but I'm definitely off to a more stable start. So far, I have basic CRUD operations available (whether they'll all be utilized and/or available for each kind of user can be decided with my role logic) for 8/10 of my major tables! I'm thrilled that I'll be able to basically build 'widgets' of sorts and combine them in whatever ways needed. Thank you so much!

The only thing I'm having trouble with is my stupid .htaccess file, but I think that's coming down to some folders having different group permissions than others and since I'm using MAMP as www, I just have to fix some permissions and I'll be good to go there.


Big Grin
Reply




Theme © iAndrew 2016 - Forum software by © MyBB