Comments (13)
There is a TON of code in there that probably NEVER gets used. Specifically:
krumo::classes()
krumo::interfaces()
krumo::include()
krumo::functions()
etc...
I thought about removing them, but I didn't want to negatively affect users. I don't know if it's possible to make those part of an optional module or something. If we're looking at 1.0 release it might be a good time to cut them all together?
Basically removes lines 55 through 431. That's 26.5% of the code.
from krumo.
My primary goal isn't "more features". In it's current state Krumo does what it needs to do, and it really shouldn't grow into an abomination with countless features that nobody needs. At first i'd like to work on the current codebase, to ensure that the present functionality is in a good state, without adding any new functionality. In fact - if it's up to me - we could even cut out some dead code, while we're at it. :-)
from krumo.
Hi,
I am following this list with one eye.
I personally did a rewrite of krumo, which unfortunately for now is only available as a Drupal module.
https://drupal.org/project/krumong (think I mentioned it already somewhere)
Disclaimer: The comments here are all out of memory, and may not exactly represent what is actually going on in the module.
The main important thing I did there was to separate tree traversal (and "hive" management) from html output.
The rewrite has two classes for tree traversal, one "depth first" and one "breadth first".
Then it has a number of "theme" classes: One for the regular html output, one that reproduces var_dump() or print_r() etc.
I don't remember whether I actually implemented that, but I had the idea of a 3rd layer for value rendering. The idea was to have different plugins for different types of "special" data. This way you could have special displaying of colors, timestamps, instances of special PHP classes (e.g. some native classes that are special), etc, without bloating the main class.
I think this direction was definitely a good idea. You should do the same, and only then start with new features.
from krumo.
Another thing i changed was to output json instead of html, and then use client-side javascript to construct the html structure and bind the events.
Without js and css, the krumo html is quite useless anyway.
from krumo.
That's another thing I was thinking about, thanks for reminding me... We need some sort of CLI mode. Even if initially we just detect CLI mode and wrapper around var_dump() or print_r() that would be handy.
from krumo.
We could also look at making the unstyled (broken/missing CSS) version not be TOTALLY horrible. That way if your CSS isn't readable or something else weird, the output you get is still SORT of usable.
from krumo.
Would it be an acceptable option to let the user decide whether to output html or CLI ? E.g. krumo() spits out html, while Krumo::print_r() spits out print_r equivalent..
(not sure whether static methods or floating functions are the way to go here)
from krumo.
We could certainly let the user pick the output type.
I think we should be "smart" and detect if the script is in CLI mode and output text mode unless the user specifies otherwise though.
from krumo.
detecting CLI isn't hard. We should do that, yes.
from krumo.
I've created a "next" branch on my repo, and I've started work on some of the things discussed above.
Another thing I'd to see is a set of community agreed up defaults. I'd like to make the krumo.ini totally optional. I want the default krumo.ini to be 100% commented out. The only reason you change anything in there is if you want some non-default behavior.
I want Krumo to be as "zero-configuration" as possible. My goal is:
- Download
- Untar
- Fully functional Krumo
No configuration required unless you want something specific.
from krumo.
No, no, we should leave the default krumo.ini in, we should just change the behaviour of setting config.. It should work by overriding specific settings, instead of replacing all of the settings, when you call config manually.
from krumo.
Yes definitely leave the config there, I just want all the options commented out (i.e. default). That ways it's less daunting for a use to look at changing things. Right now the config contained several default settings, like truncate length, and show version, and separater etc.
See:
https://github.com/scottchiefbaker/krumo/blob/next/krumo.ini
from krumo.
Maybe we should make a separate thread about this, but the config should not be commented out. Those are the defaults, in one convenient place. And then the user can override one or more or zero of those by calling the config function from their code.
We should provide the .ini file, with sensible settings, to use it "out of the box".
from krumo.
Related Issues (20)
- Escape <!-- and I suppose --> HOT 6
- krumo provide more info on a array-casted object than on the object itself HOT 4
- Feature request (and patch) : shift+click to expand all HOT 8
- Javascript bug in version 0.5.6 HOT 4
- Non-static method called statically HOT 14
- Typo in README.md "Usage" section example HOT 1
- Don't truncate after 50 characters HOT 5
- Undefined index: class:: HOT 7
- Update Packagist? HOT 3
- How to change skin? HOT 17
- krumo not showing private and protected properties HOT 2
- Is it possible to 'queue' so they can be displayed in bulk at once HOT 2
- Dropping VERSION file in favor of a class constant HOT 1
- Using a separate method for returning Krumo dumps instead using KRUMO_RETURN as argument HOT 1
- Drop the INSTALL file HOT 1
- Put composer.lock in .gitignore and drop it HOT 3
- Drop "@static" and "@access public" HOT 2
- Drop KRUMO_DIR, replace with __DIR__ HOT 1
- Change how configuration is operated HOT 2
- Krumo doesn't cleanly support PHP 8.1 HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from krumo.