search

Frug / AJAX-Chat

A fully customizable web chat implemented in JavaScript, PHP and MySQL which integrates nicely with common forum systems like phpBB, MyBB, FluxBB, SMF and vBulletin. A Flash and Ruby based socket connection can be used to boost performance.
http://frug.github.io/AJAX-Chat/
548 stars 300 forks source link

addded directory "bin" in root folder, implemented command line php scri... #176

Closed stevleibelt closed 10 years ago

stevleibelt commented 10 years ago

Hey guys,

first scribbled implementation (but working and safe) for easy up dealing with users. I would like to do the same for channels and refactor the created code to an elegant way. Any important remarks?

Thanks so far for the great project.

commit message

added directory "bin" in root folder, implemented command line php scripts to add, delete and list users. Added *.example files and copy them if real files does not exist.

usage

php bin/users.php
stevleibelt commented 10 years ago

To clear things up, I don't like to add users per hand and configure "regular" tasks per hand, thats why I started writing this console helpers.

stevleibelt commented 10 years ago

I'm not happy with the provided solution, especially since I want to extend the feature. I will finish my implementation and create a new pull request afterwards.

Main idea is to provide a way to easy up maintaining this software on the command line, this includes updates between versions (the main goal why I forked this).

Frug commented 10 years ago

I think a CLI for adding users could be really neat, but beyond anything most of the userbase will be able to do. I have no problem adding a folder for it if it stays isolated. The codebase for chat is old and needs replacing. Things like user management should be done with dependency injection. If you're doing this for yourself though, why not use a database to handle users. Chat also should have a PDO database option, for which SQLite implementation would be trivial I think.

stevleibelt commented 10 years ago

Sure,

I would love to do DI and also use components for reaching my tasks (like symfony console for example). A database for user management would easy up a lot but right now, I don't want to break with the existing code base, meaning keep it simple and do not build a bit application out of it. But right now/first draft, I could handle the file way also, later on we have to decide together what kind of software we want to use, preferred way should be to use composer/packagist of course. Lets see how far I can get. Otherwise, we need to have a chat/mail round and write down some goals/acceptance criterias.

Something totally different, is the directory name "chat" really the preferred name? I'm more a fan of the generic "public" name.

gWorldz commented 10 years ago

The only problem with renaming chat to public is the chat is usually a subdirectory of public in the majority of user setups. By labeling the directory chat it is apparent that the included files are part of the chat and not part of whatever system they are being integrated with.

stevleibelt commented 10 years ago

Hi gWorldz,

thanks for this hint. Then, "chat" makes totally sense indeed.

Frug commented 10 years ago

Composer is a possibility for 0.9 onward but I find the way it installs tests and docs to be annoying. Its components are useful, but that usefulness is reduced by the fact that right now all I have to do to "deploy" is push to github. I can't ask users to run composer themselves. I'm on the fence about it still.

stevleibelt commented 10 years ago

Another valid objection, and of course, currently, there is no high complicated logic inside the code (at least what I did so far in my fork), meaning there is no real need for composer so far. But since you provide a zipped version, you can pack this version with all vendor packages installed.